search

jonasoreland / runnerup

A open source run tracker
GNU General Public License v3.0
751 stars 274 forks source link

Development focus #586

Closed davidedelvento closed 4 years ago

davidedelvento commented 7 years ago

This message would probably have been better for the chat, but since I don't want to create an account there (I have too many accounts and I can't add one otherwise I die), let me write it here.

I've been using RunnerUp for about a month now, and I've been watching development for about half of that time. So I'm definitely a newbie.

First of all, I'm glad RunnerUp exist and it is open source. It is a great piece of software and I sincerely thank @jonasoreland (and the tiny community around him) for making it happen. That said, I think it would benefit from a shift in focus. What do I mean by that and why?

Well, the UI is a little bit confusing, there are lots of options, and it does not seem to have a focus on a particular goal. Lots of feature requests that I've seen (including mine for which I intend to create PRs) tend to be on their own, without a unified vision. I think RunnerUp would benefit from a refresh that would try to unify things and make them more consistent toward one or more goals. Without making RunnerUp the kitchen sink of the running up, with a talking dog and a dancing paper clip, just to mock a famous software project.

One example are audio cues. I've not yet fully understood them. I think for a while I've gotten audio cues during warm up and cool down, but now I don't anymore and I'm not sure what I changed, or if I simply recall something incorrect. The interface should make it totally obvious if this thing is possible, and if it is, how to enable/disable it.

For a better example, see issue #587

Now, this is your baby, so why I'm asking you, @jonasoreland, to shift focus? Well, I'm not. What I'm really asking is if you agree with this, and whether or not you think you will go in this direction (as time permit, and giving the priority to what you deem appropriate). Because if you do agree with it, I'll immediately switch what I'm doing for the PR to be so focused on some goals, such as the one described in issue #587 -- otherwise, I'll keep doing "random things" that I care about, as I'm doing so far (but I think will be less useful in the long run of the project).

gerhardol commented 7 years ago

RunnerUp goes where developers take it, Jonas accepts most changes. So if you want to do something, communicate with Jonas and do it.

However, development is a little slow right now. It can take months for PRs to be accepted (also for details like translations). RunnerUp may not be Jonas major focus right now. That is not strange, interest may be lost. I have considered forking RunnerUp, make my builds available to the public but I have other projects to maintain too, limited time.

I have played around a little with the UI, do not have anything usable. I am waiting for a bigger cleanup to be merged (#524). In addition, I suggest that the current builds are separated in Play ('RunnerUp Classic Lite', without maps/graphs for Froyo and 'RunnerUp Classic' from Ice Cream Sandwich and develop for maybe 4.4 forward for a new UI. Jonas has not agreed on that. While waiting, I have mostly stopped using my phone when running (and given up on Android Wear). (I have not used RU workouts, only as a datalogger.) It takes too much time to back out all pending changes to test new, takes out the fun for me. While waiting, I will probably just backport minor changes, "random things".

It is great to have an open source alternative.

davidedelvento commented 7 years ago

I have no problem with development being slow. I have a life (including running ;-) and a full time job that take priority. And improving my piano playing. So as time permits for everybody is just fine for me (however it would be great if it were faster...)

What I'm asking here is if we can have a discussion about where we would like RU to go, instead of letting it go by "random walk". Then, of course, RU may or may not go where we would like it to, depending on everybody's efforts and priorities.

If I understand you (@gerhardol) right in between the lines so to speak, you are saying that you would like faster development and a more focused one, making strategic decisions such as the splitting the builds (or support impromptu runs), instead of doing "random things"?

Marx2 commented 7 years ago

I think it's very important for RunnerUp to partner with open-source cloud solution. Natural target is Runalyze - also free software, possible to host locally. They have live community which constantly improves Runalyze. Unfortunately they still didn't deliver API to integrate. Maybe they would make it faster seeing interest from our community - unfortunately I don't see such demand.

Bigger level of integration would be very helpful - for example setting types of run, types of used equipment, displaying advanced statistics. Runalyze could also act as a backup of data - as I see RunnerUp automatically deletes old ones.

Of course I also like Strava or Endomondo synchronization - it should stay if possible. But having Taipiriik (also open source) configured gives us possibility to synchronize it later and don't constantly fix synchronization issues. Just synchronize to Runalyze, and then run Taipiriik to have workouts wherever you like.

I would welcome improvements in Android Wear application. I miss current time on screen, also Android Wear 2.0 support and it's complications would be very nice. Running RunnerUp standalone on watch would make such watch very versatile device. I would like to have current BPM displayed also.

As for application I agree that redesign would be very nice. Application is not user friendly for newcomers. However I don't think it's so much important now. As for audio cues, it should be possible to change its configuration during run, without interrupting it.

cmmata commented 7 years ago

There's a TODO list that gives a bit of focus on what is done and what is wanted to do. The problem is that it's outdated (Jul 2015). Maybe it could be helpful to update and maintain (at least every 6 months for example) this TODO, so developers can take some direction as @davidedelvento says.

If it takes too long to accept PR's, maybe it could be a good idea to have more developers with permission to accept PR's. Anyway, as I commented in #564 I'll be adding some tests to the app. I hope that should be helpful to accept PR's, because it will be automatically tested that the app doesn't break.

Finally, there's a suggestion in #295 to update UI, and I said that I'll be working on that too (and publishing screenshots and accepting suggestions, as I think the UI shouldn't be only in my taste). Maybe it could be interesting to add a new branch and accept UI PR's there, as it could be really strange to have some screens with a new UI and some others with older. The UI branch should be merged to master when almost all screens are updated.

jonasoreland commented 7 years ago

Gerhard,

What do you think about about letting you get commit rights to my clone ?

/Jonas

On Fri, Jul 28, 2017 at 10:34 AM, Carles Mata notifications@github.com wrote:

There's a TODO list https://github.com/jonasoreland/runnerup/blob/master/TODO.md that gives a bit of focus on what is done and what is wanted to do. The problem is that it's outdated (Jul 2015). Maybe it could be helpful to update and maintain (at least every 6 months for example) this TODO, so developers can take some direction as @davidedelvento https://github.com/davidedelvento says.

If it takes too long to accept PR's, maybe it could be a good idea to have more developers with permission to accept PR's. Anyway, as I commented in

564 https://github.com/jonasoreland/runnerup/issues/564 I'll be adding

some tests to the app. I hope that should be helpful to accept PR's, because it will be automatically tested that the app doesn't break.

Finally, there's a suggestion in #295 https://github.com/jonasoreland/runnerup/issues/295 to update UI, and I said that I'll be working on that too (and publishing screenshots and accepting suggestions, as I think the UI shouldn't be only in my taste). Maybe it could be interesting to add a new branch and accept UI PR's there, as it could be really strange to have some screens with a new UI and some others with older. The UI branch should be merged to master when almost all screens are updated.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jonasoreland/runnerup/issues/586#issuecomment-318594876, or mute the thread https://github.com/notifications/unsubscribe-auth/AABYS6yLiDrly4Sm7N0MIi9FVFACBqtLks5sSZ0VgaJpZM4Okn9h .

gerhardol commented 7 years ago

@jonasoreland Sure, then I can merge trivial like translation, Gradle plugin and documentation and other where you or other have approved changes. It is also possible for me (or others) to handle changes in separate branches, so the development is kept "home".

Of course we need to agree on the future direction, not just the small updates to master. For instance to spin off the current version as "Classic" branches and to do the majority of development with less constrains.

jonasoreland commented 7 years ago

re split classic: even if i don't personally think it's a great idea, i think we(you) should do it...cause I (currently) spend so little time on RunnerUp...

if you get commit rights, you can do (more or less) what you want right ? i'll review & comment as much as i can.

i can still do releases ?? (or should we share that too ?)

/Jonas

ps. the major contributing factors to my decrease in involvement are

On Fri, Jul 28, 2017 at 12:43 PM, Gerhard Olsson notifications@github.com wrote:

@jonasoreland https://github.com/jonasoreland Sure, then I can merge trivial like translation, Gradle plugin and documentation and other where you or other have approved changes. It is also possible for me (or others) to handle changes in separate branches, so the development is kept "home".

Of course we need to agree on the future direction, not just the small updates to master. For instance to spin off the current version as "Classic" branches and to do the majority of development with less constrains.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jonasoreland/runnerup/issues/586#issuecomment-318621222, or mute the thread https://github.com/notifications/unsubscribe-auth/AABYS2DI7J3mIl8RGByackFgJc8ZjwTXks5sSbtggaJpZM4Okn9h .

gerhardol commented 7 years ago

For an open source project like this without any commercial considerations it is important that development is fun. All development benefits if those working with it are using the product and if the dev cycle is fast so not those that are moving are slowed down. Jonas has published the Android version statistics, but if old versions are obstacles, nothing will be done for the future. "classic" versions can be maintained separately.

Releases with new features can be done on GitHub, then updates can be tested by more users, i.e. before beta cycles. However, it would be helpful to have the signing key, then it is easier to install updates for users (no need to uninstall when switching between official/test versions).

The Play developer console is useful for logs etc too even if releases are not done there by other than Jonas.

davidedelvento commented 7 years ago

I personally like the idea of the split, especially if it could be done "automagically" by the app store, i.e. the name of the app is the same and people are presented a different version depending on the device they have, as I've seen done by some app. Now sure how hard that is too achieve, though. But we should discuss that on the appropriate "strategic" github issue (#?) not here.

For this issue, as @cmmata said, a great starting point would be to start from reorganizing the TODO list and made it more prominent. Items in that list should be associated with github issues, and have only the "big picture" (e.g. again, one TODO item could be #587 which, like any other, will include several other mini and micro parts, tracked as separate issues on github).

Moreover, some level of "project management" would also help to make things more timely. @gerhardol since you seem to care a lot about this, would you like to take the lead on management? I care a bit and can provide some help, if you'd like. At first it could just be setting priorities, assigning github issues to people, and pinging them periodically to see if they still intend to complete the work they said they wanted to do. Often times a little bit of nudging is all that's needed to have developers do the last mile (ehm byte ;-) and complete their PRs. Later it could be more (we can talk separately about it). Of course you will be delegating sections to others. For example (if it wasn't already clear :-) I'll be happy to both lead, organize and develop things related to the #587 which (without discuss the details here) would be things like making a PR for including it in the TODO list, sifting through open issues and open PR that seem related and chime in those, create new issues as appropriate (as I've already done, albeit those issues at the moment live in my fork), etc. In this case probably I'd also do most or all of the development, but it does not need to be that way.

It would be good if somebody (@gerhardol again? I can help though) could go through old issues and old PRs and "aggressively" close the stale ones that will not be merged/implemented/fixed. What's the point to keep them around? Closing them will make the work of the previous paragraph much easier. It would also be good to use issue categories (e.g. new feature, bug, etc) and assign issues to people, so everything is more clear and easier to find (= less time fiddling on github, more time writing code).

gerhardol commented 7 years ago

Multiple APK: This is already done in RunnerUp, devices older than 4.0.1 gets the "Lite" app without charts/maps. However, I propose that separate apps "RunnerUp Classic" and "RunnerUp Classic Lite" are added too, for those that actively prefer the old version. https://developer.android.com/google/play/publishing/multiple-apks.html (Sidenote: I added issue #588 to make even more APKs, may confuse users not installing from Play with multiple dimensions...)

Sure, I can take some lead (I normally prefer to be a developer rather than a project manager, but lead can involve both). For an app like this it is not so much following up but to be a "merge coordinator". I take pride in what I commit to, and will therefore have a disclaimer that I occasionally am very busy at work and may not contribute forever.

davidedelvento commented 7 years ago

@gerhardol if I understand your proposal, I like it. Let me try to be explicit. We (somewhat, details to be discussed) create 3 different APK (possibly with different names, TBD) as follows:

If that's the case all this "shift in focus" can happen in the latter version only. The first two versions can go in "maintenance mode" only, with little development happening. And being something "new", we do not need to worry about breaking the "old", so we can get rid of stuff we decide not to support. For example we can merge PR #524 without worrying too much.

Now, if that's the case, the question becomes: how better to achieve this? It could go from "silent" choice depending on device, to totally different app with different name by different maintainer (friendly fork of RunnerUp). I'm open to any option.

gerhardol commented 7 years ago

If @jonasoreland signing keys and Play account is used, then they should used for all new additions. If he prefers to not use the account a separate Play account need to be added. New application name too? If separate, "new" is a fork. I prefer to not fork, the user base is enough. The changes discussed are a small part of what has been done to the app.

Proposal:

Now:

Soon:

When something new is done:

When "new" is stable:

Marx2 commented 7 years ago

I think it's better to make things simply. Just leave current Runnerup with the name it already have and create new one with softly change icon (for example make runner red) and expanded name. "New" in the name is quite bad idea. Better would be "Runnerup advanced" or "runnerup NG" like new generation. It would be also very useful to use beta area of Google play. That way many people would test beta version.

jonasoreland commented 7 years ago

i think put all new dev into existing "RunnerUp"

and if someones puts in the time/effort make a RunnerUp classic...though my guess is that it won't happen...

On Sat, Jul 29, 2017 at 12:12 PM, Marx notifications@github.com wrote:

I think it's better to make things simply. Just leave current Runnerup with the name it already have and create new one with softly change icon (for example make runner red) and expanded name. "New" in the name is quite bad idea. Better would be "Runnerup advanced" or "runnerup NG" like new generation. It would be also very useful to use beta area of Google play. That way many people would test beta version.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jonasoreland/runnerup/issues/586#issuecomment-318818797, or mute the thread https://github.com/notifications/unsubscribe-auth/AABYS10wsG8f53XJcG_izzAK9E_GpDpsks5sSwV0gaJpZM4Okn9h .

davidedelvento commented 7 years ago

See if I understand correctly, and if people like this, which is somewhat simpler, in my opinion.

Now:

Future (very soon, I'd say immediately as soon as @jonasoreland can do it):

Lite and Current will probably be semi-frozen, if not totally frozen, however new features and bugfixes could still happen if people are interested (just to be clear: I will not participate in that effort, other than perhaps comments on PR and issues in github)

gerhardol commented 7 years ago

@davidedelvento : @jonasoreland said no to a "Lite" and "New" version so all is implicit

All build binaries should be put on GitHub (I suggest on F-Droid too) so a 7.1 user can install Lite(Froyo) if preferred).

I want Lite(Froyo)/Classic to be maintained from a maintenance branch, "New" from a separate branch. That way older workarounds can be removed.

There could be a Lite(New) version too, without charts/maps. The current uncompressed size for Classic is 34MB (apk 15MB), for Lite 5MB (apk 2.5MB). If #588 is implemented then Classic is 7.5 MB (apk 3,7MB), so maybe there is no need for a Lite(New)? Note: The non-Lite version has elevation compensation for GeoId adding uncompressed 1,1MB. This could be dowloaded on demand (this requires some integration with the Play account, hard to separately, some solution needed for F-Droid users too?).

davidedelvento commented 7 years ago

I'm fine with having versions picked up implicitly.

I agree that we need separate branches for the older versions (the "new" could be in the trunk).

Maybe I am a naive user, but I don't see any issue with file size, and I'd rather have something that works out of the box than something more complicated to be downloaded later. I think elevation compensation is very important and I would not make it optional.

Marx2 commented 7 years ago

I agree with Davide. I wouldn't worry file size, especially in new version. I don't know if it's possible, but adapters for external services are parts which breaks most often. Ideally they could be developed as plugins and used for every version. Old versions without upgrade potentially will lost possibility to upload and become useless. Alternatively Runnerup could cooperate with Taipiriik and trash all upload code leaving only Taipiriik. Taipiriik updates it's code quite often, more often then currently Runnerup is doing this. That way upload code would be up to date more often

pon., 31.07.2017, 21:01 użytkownik Davide notifications@github.com napisał:

I'm fine with having versions picked up implicitly.

I agree that we need separate branches for the older versions (the "new" could be in the trunk).

Maybe I am a naive user, but I don't see any issue with file size, and I'd rather have something that works out of the box than something more complicated to be downloaded later. I think elevation compensation is very important and I would not make it optional.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/jonasoreland/runnerup/issues/586#issuecomment-319164499, or mute the thread https://github.com/notifications/unsubscribe-auth/AAyOZoMeZpWMK4K8MtNhWEZ1QMIUN2_mks5sTiSPgaJpZM4Okn9h .

davidedelvento commented 7 years ago

@jonasoreland @gerhardol it looks like we reached and agreement.

Now the question becomes: for the PR regarding this new version, should I target trunk or should a new branch (or directory) be created? I'd rather have this sooner than later (even if the PR would then take time to be reviewed and merged). Thanks!

gerhardol commented 7 years ago

Size: There has been some complaints (including Jonas) about increased APK size since MapBox update. Many run with "second phone" with limited resources. Personally, I cared about the size being 7 or 40MB when I had an Android watch with badly partitioned memory. Anyway, I submitted #595 and hope we can skip a Lite(New) flavor. (And I prefer to have GeoId compensation included by default too, but it could be downloded when installing.)

Synch: You can use Tapiriik by using FileSynchronizer and save to dropbox (script required to copy?) or sync via Strava or something else. (Does Tapiriik even have a push interface? I assume push will require the paid Tapiriik version.)

RunnerUp could release a lot more often than it does right now but synchronizers still need to be implemented. Native interface enables other features like direct links to the activities.

cmmata commented 7 years ago
  • Implicit Lite (froyo) for android pre 4.0.3
  • Implicit Classic for 4.0.3-4.4/5.0
  • "New" for later (really no change)

I assume that it could be great to have tests on all versions (branches), new and old. But what about the new UI? In #295 there is a proposal for having 4.4 or 5.0 as minimal versions to receive the updated UI, but the new app is for >5.0. Should I point the UI PR's to the "New" branch only? Or "implicit classic" should receive it too?

To make things easier, I'll start with the new UI as soon as the main repo has the new branches and lint PR's accepted. Meanwhile, I can start with adding tests.

gerhardol commented 7 years ago

Minimal version: My opinion is to support "New" from 4.4 or 5.0 so a "below" is missing above. 4.4 has a a fair share of users that could be interested in an updated application but 5.0 adds native support for Material Design requiring less workarounds. So if @cmmata starts on a new UI, minimal is implicitly chosen!

Merge order for master (the following I want to have in next Classic too, decision for "new UI" etc separate branch is separate), @jonasoreland to decide:

Before next official release:

574

573

Next:

595 (#572)

591

610

602

609 (#590 #589 #593 #596 #599 #608 )

600

524

Wait a little

594/#596 (DBVERSION is not to be changed yet)

classic/ng split. (tbd if classic releases are to be released from this commit or the 1.58 commit) There is now a master/ng or a classic/master branch

Remove "Froyo" branch - keep only one flavor Set minimal SDK version to 5.0 (?) Some Lint cleanups related to raised version (remove workarounds required before, some suppression)

davidedelvento commented 7 years ago

My opinion is that:

  1. it's a waste of time to support anything older than v5.0 (API 21), particularly because of Material Design and
  2. there isn't anything compelling to support only versions newer than v5.0 (API 21)

Therefore, my preference would be to target v5.0 (API 21)

I know about the distribution of users in #404 which says that almost 30% of users are using something older than v5.0, however:

@cmmata for the tests, I think they are most useful when the codebase is changing a lot and/or when TDD is used, which I don't anticipate to happen for the two versions (that exist today). Therefore, I suggest that for both UI and tests, you spend your time on the new version targeting v5.0

In conclusion, my strong preference is to target v5.0 (API 21)

jonasoreland commented 7 years ago

let's got for >= 5.0 then ?

(if 5.0 is sufficiently new??)

/Jonas

On Tue, Aug 1, 2017 at 4:35 PM, Davide notifications@github.com wrote:

My opinion is that:

  1. it's a waste of time to support anything older than v5.0 (API 21) and
  2. there isn't anything compelling to support only versions newer than v5.0 (API 21)

Therefore, my preference would be to target v5.0 (API 21)

I know about the distribution of users in #404 https://github.com/jonasoreland/runnerup/pull/404 which says that almost 30% of users are using something older than v5.0, however:

  • How these users are counted? I have a v2.3 device where I installed RU, but I never use it anymore. Am I counted?
  • The numbers there are one year old: how much has changed since?
  • I'm not asking to not support anything on these older devices, just to leave alone what it is current available and not giving them much new
  • Today one can buy something like a Samsung J3 for $150 (taxes and shipping included). Unlocked, running Android v6.0.1 (API 23), and rumored to soon be updated to 7.x -- In fact I bought such a device exclusively to run RunnerUp on it. Frankly, I don't want to spend too much time for anybody who claims to care about their running app, and then wishing to run on their decade old Android v2.3 or even v4.x: what is available today is good enough for them (maybe occasional bugfix and occasional simple feature request)

In conclusion, my strong preference is to target v5.0 (API 21)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jonasoreland/runnerup/issues/586#issuecomment-319389072, or mute the thread https://github.com/notifications/unsubscribe-auth/AABYS1T8d4asZS3zdTSEQX36dK2X0D9Lks5sTzejgaJpZM4Okn9h .

davidedelvento commented 7 years ago

@jonasoreland

if 5.0 is sufficiently new??

Looking at all versions x > 5.0 from wikipedia in box 5.1 and subsequent ones I can't find anything that let me think we'd better go for version >= x. For x=5.0, there are.

gerhardol commented 7 years ago

I have commit accaess to this repo now, discussing a little with @jonasoreland how to handle branches before committing. Merge plan a few posts above.

gerhardol commented 7 years ago

Some discussions for how to work, so we use resources in the best way. I have investigate issues and tagged them with enhancement/bug if they seemed to be relevant and closed fixed issues and questions. There are still 124 issues (Most of the 20 still open PRs should be merged to master.)

Documentation currently in Git should be moved to the Wiki: CONTRIBUTING SYNCHRONIZERS TODO Documentation/ All can edit, also those not setup as collabrator (I have done a quick cleanup).

Collaborators: Jonas has added me as a collaborator, so I can merge and handle issues. It is only possible to assign to collaborators, so to have some overview of what is being done just issues and projects are incomplete for "external" users like @davidedelvento right now (there will always be other...). GitHub has a relative simple protection model where branches can be protected but the permissions are quite coarse.

Therefore, some wiki based "assignment" need to be used in addition to issues and pull requests (with comments).

Release naming and milestones: I propose naming here: https://github.com/jonasoreland/runnerup/issues/607 Then we can set v1.59 for issues/PRs that should be included in next release, classic_next for unscheduled targeted for next "Classic" and runnerup_ng for new development.

branch usage: I propose master and classic branches. 'classic' branch to be created later where relevant (before legacy features are removed).

merge criteria: all commits should be done from merge requests. (master branch should be protected) Reviews should be done, I do not want enforce that now

cmmata commented 7 years ago

If you cannot assign an issue to a external collaborator, maybe you can add tags to issues like 'help-needed' and 'in development'. If any external collaborator has an "assigned" issue, you can add that in the issue comments. That way people can see what issues are pending collaboration and what other are being developed.

Besides that, branch usage, milestones etc. look fine.

gerhardol commented 7 years ago

@cmmata Such labeling must be done with milestones. "in-development" would be the generic runnerup_ng label, help-needed would be a separate milestone. We could of course add milestones like user_cmmata as a workaround, but only collabrators can assign milestones. Maybe milestones assigned/unassigned are sufficient. (You cannot filter multiple milestones at the same time though.)

This will not be a major size project and we can change over time. Just enough structure to keep chaos away, important is to having fun.

cmmata commented 7 years ago

I have moved 'how to build' files from Documentation to its wiki section. Are webservices.txt and workout.txt still needed? Maybe webservices.txt could be merged with Synchronizers page.

gerhardol commented 7 years ago

SYNCHRONIZERS are for users, webservices.txt for developers It is a matter of formatting if they can be merged (there is information in the source code comments too).

davidedelvento commented 7 years ago

@gerhardol @cmmata

Github has many quirks. For example, it's easy to find issues which mentions me or I authored but it's close to impossible to find issues I commented on (but did not author nor mention @davidedelvento). So, often times when I comment, I mention myself (like a signature), you might have seen that, and might want to do the same for yourself.

We just have to live with what we have. For assigning issues to non-collaborators, I suggest the following, which is serving me well.

1) when the non-collaborator (e.g. me) forks the repo, he or she goes into the fork settings and enables issues (among the "Features")

2) once the issues are enabled, anybody can create issues, so either @gerhardol or the non-collaborator him- or her-self can 2a) create an issue in their fork and mention the corresponding issue in the jonasoreland repo. Github is smart with this, see for example https://github.com/davidedelvento/runnerup/issues/16 and the corresponding #557 which automatically mentioned the former. 2b) the non-collaborator can then assign the ticket to him or herself.

I suggest not using "help needed" (which usually means nobody is working on it, and is soliciting others to work on it). I'm neutral about the "in development".

@gerhardol Whoa, you're working hard on this, it's tricky to keep watching the repo with everything you're doing! Looking forward to the cleanup!

gerhardol commented 7 years ago

For "up for grabs" I have used "no_target" so far. Miss to tag with product relate too, like 'synchronizer', 'hr', 'device', 'gui'.

gerhardol commented 7 years ago

For "new branch": @cmmata has started on the cleanup branch (#524). I believe that can be merged to master now, I have tested what I can (unfortunately, it seems like no one will review it).

I started some minor test with Material Design in the beginning of the year and adopted most views to use AppCompatActivity. That is in my branch feature/appcompat-changes I have reviewed it and it does look OK I believe. The PreferenceActivity needs some rewrite (not too bad) to derive from AppCompatActivity too. The functionality seem OK to me (some testing). There are no major reasons for classic to merge this.

Using AppCompat is not critical with minSDK=21 but it can be good for the future. If classic and ng are similar it is easier to merge changes.

Should the Material Design start from the appcompat-changes or should I drop it? The master_ng branch has few changes compared to master, but it is still a pain to maintain two similar branches, a third appcompat branch is even worse.

davidedelvento commented 7 years ago

@gerhardol I think you should drop appcompat. I don't see any need to maintain it, unless you really plan to start working from there, sooner rather than later.

If you think the work is worth preserving, make sure @cmmata sees it, in case he wants to reuse any of the code. Note that that on github there is no such a branch. Maybe it's just in your personal repo? If you do push it to github (as opposed to privately showing it to @cmmata), make sure you mark it with something that makes it clear is an experiment.

gerhardol commented 7 years ago

feature/appcompat-changes was pushed some time ago to GitHub in my repo I opened https://github.com/gerhardol/runnerup/issues/1 to track this, but I will

524 and master_ng has been updated from master (raising min SDK is the only difference to #524)

davidedelvento commented 7 years ago

Ah, I see. I was searching for it here in jasonoreland repo.

12people commented 6 years ago

@davidedelvento About the minSDK—Android's support library supports key material design components back to Android ICS (minSDK 14), but many also to Android 2.1 (minSDK 7). So there's no need to change the minSDK.

gerhardol commented 6 years ago

Google drops support for old versions as time passes, similar for the libraries used. Using something older than Lollipop will require more workarounds too. The old version is not dead just if development is focused on newer versions. In this case, support for old versions slowed down the development so the restart has been really slow...

12people commented 6 years ago

@gerhardol I've worked on Android apps and from ICS on, the support libraries, as they stand now, work quite well. I KNOW for a fact that bringing material design to an app from ICS (API 14) onward is absolutely no problem.

Are there any actual issues that developers are running into that would call for a higher minSDK version? If so, what are they?

gerhardol commented 6 years ago

You will need to use ActivityCompat at least. I started that but that is not finished. There were some other workarounds that was needed too. But the minimum version will be raised step by step and older versions will have to be dropped at some point of time. Minimum was Froyo until a year ago, now it is raised again to ICS.

gerhardol commented 6 years ago

Not the core app, but the UI should be rewritten. Not much progress though.

2018-03-18 22:27 GMT+01:00 Mirek Mazel notifications@github.com:

@gerhardol https://github.com/gerhardol BTW, you mention a slow restart—is the app being rewritten?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jonasoreland/runnerup/issues/586#issuecomment-374049623, or mute the thread https://github.com/notifications/unsubscribe-auth/AF9Z5L3bbLfxzMehIPfzjf7ucFhibTLvks5tftFUgaJpZM4Okn9h .

12people commented 6 years ago

@gerhardol You mentioned you started work on moving to AppCompatActivity. I started an issue specifically for that https://github.com/jonasoreland/runnerup/issues/648 .

Would you mind cherry-picking your work on this particular issue? Using AppCompatActivity instead of TabActivity would allow us to use e.g. VectorDrawable and other things from the support library without losing compatibility with Froyo.

BTW, I'm starting work on a material design update. This bottom navigation bar, designed according to the official specs, is my first commit on the way: https://github.com/jonasoreland/runnerup/pull/649

gerhardol commented 6 years ago

@12people The partial conversion to AppCompat is available in branch: https://github.com/gerhardol/runnerup/tree/feature/appcompat-changes

gerhardol commented 4 years ago

Closing this discussion. More contributors are welcome.