Minor suggestions - Githubissues

IzzySoft commented 4 years ago

First thanks for publishing your app! May I suggest some minor "technical" adjustments?

what license is your code protected by – could you please point that out by adding a license file, or at least mention it in your ReadMe? That will help potential contributors to decide whether they want to contribute at all (to some it's quite important)
versionName of the app is "1.0.0", while the tag name says "0.1". For "just having started", I guess the latter is correct; maybe versionName should reflect this?
great to have those screenshots! which raise the question: what kind of feed is shown in the last one? Does your launcher include an RSS feed reader? Could you mention that in the ReadMe as well?
similar for the 3rd screenshot: is a dialer part of the launcher?

Please don't get me wrong: this is not meant as critizising. I'm fully aware you just started this project. I'm just summing up my fist thoughts when stumbling upon it here – hoping to give some pointers for "better presentation". Thanks a lot again!

jspw commented 4 years ago

Thanks for your suggestions. I have just made that Launcher thats why i havent add much informations for now. I will add these things as you have mentioned as soon as possible.

IzzySoft commented 4 years ago

I have just made that Launcher thats why i havent add much informations for now.

Yes, sure – the commit history makes that clear. Hard to phrase things as one means them – but I hope I got that right, as "friendly suggestions" :wink:

I will add these things as you have mentioned as soon as possible.

Cool! As time permits, of course. Please let me know here when I should check again!

And thanks again!

IzzySoft commented 3 years ago

@jspw could you please fix the APK you've attached to the tag today? Current tag is v1.1.0, but the APK has 1.0.0 – so my updater will download the same APK over and again.

jspw commented 3 years ago

Thanks,I have updated the version. Any kind of suggestions will be appreciated :+1:

IzzySoft commented 3 years ago

Thanks! Indeed, there is another one: never DEcrease versionCode. Now versionName is OK, but versionCode is back to what it was with v1.0.0:

package: name='com.example.launcher' versionCode='1001' versionName='1.0.0' compileSdkVersion='28' compileSdkVersionCodename='9'
package: name='com.example.launcher' versionCode='1001' versionName='1.1.0' compileSdkVersion='28' compileSdkVersionCodename='9'

The effect is: nobody will receive updates. To those who currently run v1.0.0, Android considers it the very same version – and to those who got the "version in between" it would be considered a downgrade (Android goes by versionCode to tell that).

So sorry, but can I ask for another update? :flushed:

PS: by the way, were did the v1.0.0 release go to? The v1.1.0 release seems to have the same time stamp (2020-09-21), while the corresponding tag is from today. I'm a bit confused. Could it be you accidentally re-used the "old" release instead of creating a new one?

PPS: the pubspec.yaml also looks a bit confusing. Let me quote lines 8-18:

# The following defines the version and build number for your application.
# A version number is three numbers separated by dots, like 1.2.43
# followed by an optional build number separated by a +.
# Both the version and the builder number may be overridden in flutter
# build by specifying --build-name and --build-number, respectively.
# In Android, build-name is used as versionName while build-number used as versionCode.
# Read more about Android versioning at https://developer.android.com/studio/publish/versioning
# In iOS, build-name is used as CFBundleShortVersionString while build-number used as CFBundleVersion.
# Read more about iOS versioning at
# https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
version: 1.0.0

"three numbers separated by dots … followed by an optional build number separated by a +"

So shouldn't line 18 rather read something like

version: 1.1.0+1101

I'm no Flutter or Android dev, but that's what I usually see in that place (well, yes, it states "optional", so I might be completely wrong here – but as I wrote, I'm no dev). So I suspect that Flutter, missing the second part, somehow constructs the "1001" by appending its default code of "1" to what it sees here after stripping the dots: "1.0.0" + "1" = 1001. Might be a coincidence, though…

I guess you maybe never had the versionCode in focus, and it just "happened" as constructed by Flutter. Now you cannot go below 2001 again (as that was the highest one already used). May I suggest a common pattern for future versionCodes for that case? Going by semantic versioning, your versionName is major.minor.patch. I've often seen projects constructing their versionCode based on that as something like 10000*major + 100*minor + patch. Which for v1.1.0 would sum up to "10100". That's bigger than that 2001 and thus would work. It's unlikely you'll have more than 99 patches for a minor, or more than 99 minors for a major, so there should be no issues with that.

It's of course totally up to you – as long as versionCode is never decreased :wink:

jspw commented 3 years ago

I will admit my lack of knowledge in these things. Can you check this release 1.1.1

IzzySoft commented 3 years ago

I'm no "pro" either when it comes to development, so above are just raw guesses.

I've just pulled v1.1.1: looks good and seems like a good way: so you decided to just increment based on the previous release (1001). As the "accidental 2001" was just released yesterday, hopefully there are not too many folks having updated already. I've hence simply replaced that, so this should be fine now. Please keep incrementing versionCode then, and versionName in-sync with tag name :smiley:

Thanks a lot for your help!

To give something back: should you be interested in a "starter package" for Fastlane structures (used e.g. by F-Droid and also in my repo), I gladly offer you a PR. Oh, and before you ask: Updates in my repo happen around 6:45 pm UTC each day, so v1.1.1 will popup there in about 7.5h…

_{(PS, disclosure: I'm one of the F-Droid maintainers, responsible for the metadata part :wink:)}

jspw commented 3 years ago

Thanks a lot, I will check it out.

IzzySoft commented 3 years ago

Just let me know then, I have it already ready :smiley:

jspw commented 3 years ago

Yup,It's nice.

IzzySoft commented 3 years ago

There you go!

jspw commented 3 years ago

Done! Please check my last commit.

IzzySoft commented 3 years ago

Thanks! Right position for the screenshots, but could you please remove the framing? Just imagine you're browsing ups with a mobile client on your 5" phone. All you see from there (without zooming every single picture manually) will be "pink blots", no details. Your original shot* files did not have that framing. Especially that "squared background" doesn't add any value: it's just an empty pink area. The "phone case" might be arguable – but don't we all know how our phones look? Keeping screenshots as they come (no frames etc) however is "optimal use of space", especially on small screens :wink:

(For the reasons just mentioned I manually remove such framing when integrating apps' screenshots with my repo. But that means no automated updating of the screenshots, as I know of no way to automate the cropping so it matches all possibilities: some use "phone cases", the next add another background layer with some words – and now for the first time I see even sqared ones)

jspw commented 3 years ago

Got it, I have cropped the images.

IzzySoft commented 3 years ago

Much better, thanks! How about adding the other two (dialer, events) as well? And do you prefer the screenshots with the phone frame over the "completely deframed" as currently shown in my repo? Then I'd enable pulling screenshots along with future app updates.

jspw commented 3 years ago

I think the screenshots with the phone frame are better though you can suggest :3

IzzySoft commented 3 years ago

Yes yes, beauty as well as contact lenses lie in the eye of the beholder :laughing:

If the screen is big enough, all's fine. On small screens, I bargain for every pixel. But the most important issue with that is solved: empty room without any value is gone now, giving room for the interesting stuff.

And my suggestion I had just linked. The last word is yours here – I'll just downsize to 350px on the small side of the images (keeping the ratio) for the sake of folks with bad connections and small data plans. That really pays: in the F-Droid app I can easily tell if an app comes from my repo or from F-Droid itself (my apps show full images – the others either miss them or take ages to load)…

So thanks a lot for going though all the effort! I'd say it definitely was worth it :smiley: If you consider this solved, feel free to close the issue then.

jspw commented 3 years ago

I have resized the images.Thanks for everything. I'm closing this issue.

IzzySoft commented 3 years ago

Wow, that's phantastic – thanks a lot! I've enabled pulling them on updates now.

IzzySoft commented 3 years ago

Hey, look: it updated today, and pulled your new screenshots \o/

(before you wonder: no, it doesn't pull GIFs, so that one is unfortunately missing here; you might wish to move it "to the top" on the readme).

Hm, how about including the settings screen and the search? :thinking: Maybe instead of the current 6+7 (which only become clear if you've already used the app, or at least follwed the demo GIF)?

jspw / Ubuntu-Launcher

Minor suggestions #1