Collect: Migrating to Android Support Library

[Andy671]

Software and hardware versions

Future ODK Collect releases.

Problem description

The app uses a lot of deprecated methods and classes. GSOC project aims to change UI and UX.
https://github.com/opendatakit/collect/issues/464 - here you can find estimated Material Design mockups that I proposed. To start refactoring of the app we should consider to use Android Support Library that brings possibilities for the redesigning.

Other information

To make Material Theme and Support Library work we should refactor Activity to AppCompatActivity, HoloTheme to AppCompatTheme, and make a bunch of small changes, including fixes of the deprecated methods and classes. These changes should be done very carefully for maintenance of the old-device users and base functionality of the app.

[allenagk]

Hi, I'm trying to give my support for UI/UX changes or unit tests through the GSOC project. So when we applying material themes as mentioned above we have to consider the old device users. So what is the lowest API that we should take care of? Then Do we have to configure our project for v21 and old so like that?

[shobhitagarwal1612]

API 16

[Andy671]

Support Library will not affect minSDK level.

Starting with Support Library release 24.2.0 (August 2016), the minimum supported API level across most support libraries has increased to Android 2.3 (API level 9) for most library packages.

Reference

[lognaturel]

Thank you for getting the conversation started, @Andy671! What I'd like to make sure we understand in the short term is whether there are ANY UI, performance or functionality implications to changing the base classes. That will help decide if we should do it now or as part of someone's GSoC UI project. It's something I'm not too familiar so I'm interested in your experience and any references that address that question.

[Andy671]

@lognaturel We have two options here.

1. Rewrite the app from scratch.

2. Do research throughout the code of the app and the Support Library to inspect changes and refactor the project gradually. Android Developer Documentation is not very informative on this topic.

These two approaches are both long roads. Tomorrow, I will do a deep dive into the 2nd option, just to understand which way would be more appropriate.

[lognaturel]

Thanks @Andy671. We will do 2 because a full rewrite rarely results in something being shipped. The question is more about timing. Should this change be done now for the next release or is it better to include it with the full UI change.

[shobhitagarwal1612]

@lognaturel Maybe should add the android support library right now so that we can start replacing deprecated code being used in the app or add latest features to the app which are added to newer APIs

[Andy671]

@lognaturel Full UI change can't be done in one step because of deprecated code and inability to use new API's without refactoring huge old parts of the project. There are a lot of things should be replaced: Activity, Toolbar , TabActivity , ListActivity, etc. The heap of the Activities in the app is amiss too (modern apps use 1 activity per app). That should be replaced with Fragments. Android platform requires Fragments for Material Design patterns and modern platform API's. I propose to make one small step at a time, starting with basics. We need 3 things for the start point.

• Activity to AppCompatActivity and Theme.Holo to Theme.AppCompat.
  Hierarchy of the AppCompatActivity:

 ↳    android.app.Activity
             ↳    android.support.v4.app.FragmentActivity
                 ↳    android.support.v7.app.AppCompatActivity

So the behavior of the app when switching Activityto AppCompatActivity and FragmentActivityto AppCompatActivitywill stay the same.

• But there is a method onRetainNonConfigurationInstance that became final in FragmentActivity and we can't override it now. (This method is used a lot in the app)
  Retain all appropriate fragment and loader state. You can NOT override this yourself! Use onRetainCustomNonConfigurationInstance() if you want to retain your own state.
• Alert Dialog insignificant changes.

If you allow me I can make a small pull request with good-commented commits to see what is really happening.

[mitchellsundt]

The old recommendation for 1-Activity-per-App is no longer Google's current
advice. And from my experience with the ODK 2.0 tools, trying to apply
that for everything was a mistake, so this is a good change.

They now seem to have gone back to a multi-activity viewpoint:

https://developer.android.com/guide/components/activities/tasks-and-back-stack.html

On Fri, Mar 3, 2017 at 6:13 AM, Andrii [e-mail] wrote:

@lognaturel https://github.com/lognaturel Full UI change can't be done
in one step because of deprecated code and inability to use new API's
without refactoring huge old parts of the project. There are a lot of
things should be replaced: Activity, Toolbar , TabActivity , ListActivity,
etc. The heap of the Activities in the app is amiss too (modern apps use 1
activity per app). That should be replaced with Fragments. Android platform
requires Fragments for Material Design patterns and modern platform API's.
I propose to make one small step at a time, starting with basics. We need 3
things for the start point.

• Activity to AppCompatActivity and Theme.Holo to Theme.AppCompat.
  Hierarchy of the AppCompatActivity:

  ↳ android.app.Activity
  ↳ android.support.v4.app.FragmentActivity
  ↳ android.support.v7.app.AppCompatActivity

So the behavior of the app when switching Activityto AppCompatActivity
and FragmentActivityto AppCompatActivitywill stay the same.

• But there is a method onRetainNonConfigurationInstance
  https://developer.android.com/reference/android/support/v4/app/FragmentActivity.html#onRetainNonConfigurationInstance%28%29
  that became final in FragmentActivity and we can't override it now. (This
  method is used a lot in the app)

Retain all appropriate fragment and loader state. You can NOT override
this yourself! Use onRetainCustomNonConfigurationInstance() if you want
to retain your own state.

• Alert Dialog insignificant changes.

If you allow me I can make a small pull request with good-commented
commits to see what is really happening.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/opendatakit/collect/issues/493#issuecomment-283963237,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACLO088mOkGh9jYpiQ3Rx9PzoOFy7yw2ks5riCAngaJpZM4MQsmV
.

--
Mitch Sundt
Software Engineer
University of Washington
[email protected]

[lognaturel]

I agree with all of you that this needs to be done. I would like for one of you who has experience with this migration to let us know if there are any user experience implications. Are there any subtle bugs or UI changes that could be introduced or is this a completely transparent change from a user perspective.

[lognaturel]

Also, how does this interact with moving to a Fragment-based architecture? @Andy671 addresses this a little bit but perhaps we should consider making the changes in single Activities or clusters of related activities rather than making sweeping changes across the code base.

@Andy671 it sounds like you have ideas on how to answer those questions. Please do file an illustrative PR so we can discuss something concrete.

[swapsha96]

That would be great. We won't need much restructuring then. Basically, java files will be altered and not much changes in XML files would be required.

[mitchellsundt]

From my ODK Survey experience, the 2 big changes with the Fragment-based
Activities are:

(1) Preferences screens (all the settings). These should be updated with
the new activity / category / fragment structure. I think you just did that
in one of the recent releases.

(2) All ListActivity based activities go away. These are pushed into list
fragments with loaders that execute the queries to populate the list in the
background. And the ListActivity is converted to a simple Activity. E.g.,

class FormChooserListFragment extends ListFragment
implements LoaderManager.LoaderCallbacks>

https://github.com/opendatakit/survey/blob/master/survey_app/src/main/java/org/opendatakit/survey/fragments/FormChooserListFragment.java

In general, the recommendation is to have all content provider access be in
a background task (e.g., inside LoaderManager for list views). You can
enable the Developer option for flashing the screen red when the UI thread
is slow to see if database access is slowing down your rendering. This is
really only an issue if you have 1000's of forms to show in a list view.
This is part of the elimination of the managed cursor. Not sure if your
updates have already addressed that.

---

If you want to have an activity that adapts to the device screen size by
showing multiple fragments side-by-side, which would allow people to
interact with each fragment independently, then additional things would
change. I don't see an opportunity for this in ODK Collect.

On Fri, Mar 3, 2017 at 9:53 AM, Swapnil Sharma [e-mail]
wrote:

That would be great. We won't need much restructuring then. Basically,
java files will be altered and not much changes in XML files would be
required.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/opendatakit/collect/issues/493#issuecomment-284023398,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACLO071ZvyzuK6zBqUi-3D7HHsKSQpWkks5riFOSgaJpZM4MQsmV
.

--
Mitch Sundt
Software Engineer
University of Washington
[email protected]

[lognaturel]

Thank you @mitchellsundt, that's very helpful!

We've made some good progress on restructuring the preference and list-based activities. As we discussed on Slack, @shobhitagarwal1612 and @dcbriccetti will have a chat about moving all the preferences activities to be fragment-based. I think that's a nice, isolated set of changes that @shobhitagarwal1612 will be able to.

Other good clusters include lists as Mitch mentioned, geo (which I think @Dvik will be filing an issue for and addressing). I think approaching the change as part of a series of refactors rather than just changing all the base classes at once will make it easier to notice any UI issues that come up and to address deeper issues. @Andy671, that may have been what you were thinking when you were offering to make an isolated sample. That would be great.

[Andy671]

@mitchellsundt, thanks for the reference.
@lognaturel, I understand, that we should do step-by-step refactor, but the problem is we can't change a few of the Activities to AppCompatActivities and leave the same other ones because of applying Theme.AppCompat. What do you mean by "isolated sample"?

[lognaturel]

@Andy671 Ah, thanks for that info. If we have to apply the change to all activities at once, let's focus on addressing individual deprecated methods (#522, etc) and doing some initial restructuring of some of the activities (#507, etc) for this release cycle. We can then make the base class change at the beginning of the next one and make sure we have plenty of time to notice any potential issues.

[lognaturel]

We haven't had very many across-the-board UI changes this release and probably won't in the next one so I think we might be ready to do this without too many conflicts. And if there are any UI problems, we can pinpoint them to this change.

[shobhitagarwal1612]

I'm working on this

[shobhitagarwal1612]

Fixed #912