I am tasked with building an app that does not have a fixed screen order.
When started the app will contact a server an get a list of actions to perform.
So one launch could be
screen 1 - screen 5 - screen 7
next time
screen 3 - screen 5 - screen 9
I tested a simple app that does that; my Main activity starts the needed activity and that activity returns to the main activity, which starts the next needed activity.
In other words, all activities return to the Main activity which then determines which activity to start next.
It seems to work fine, but I have read that Activities should only be used for UI, my Main activity had no UI, it just controlled which activity happened next. So should I be using a different approach?
I am brand new to Android, but have decades of Java experience.
In case it makes a difference, I am using AS 3.0.1
Thanks
I'd suggest one activity and implementing your "screens" as fragments. This makes it really easy to code your logic for what screen comes next. You are just adding / replacing fragments and not starting and tracking result codes of activities. The business logic for each screen can still be fully encapsulated in the fragment.
Related
I have an APK that runs completely fine across several android levels varying from android 5 through 9. We started testing a new android 9 phone (Hot Pepper HPP-L55B aka Serrano), and I'm seeing an interesting issue that I'm hoping someone has come across.
All of my Activities extend a base activity that does some standard logging (such as logging onCreate, onResume, etc).
On app launch:
Activity 1 - MainLaunch
onCreate starts the activity Splash then calls finish
Activity 2 - Splash
onCreate sets the content view and finds the WebView on the screen.
onResume sets a gif in the webview so it's rendered on the splash screen. It also starts a thread that sleeps for a few seconds that then kicks off Activity 3. The gif animates as expected.
Activity 3 - Launchpad
onCreate sets the content view and finds references to other items on the screen (buttons and textviews).
onResume checks a few internal things, and may or may not hide things on the UI based on configuration. Nothing to exciting.
There are times this process will go through without a hitch, and other times where the UI that was being displayed in Activity 2 (splash) stays up while my logs are showing that the code thinks it's showing UI 3. The gif in this case is no longer animating.
As you click around on the splash screen the buttons that are referenced and would be showing on Activity 3 are being pressed. So basically like the splash screen is covering the 3rd activities screen and allowing button push pass through. If i turn the screen off/on again the splash screen still shows up. Throwing breakpoints in activity 3 get hit as the hidden buttons get clicked.
Anyone ever see this before or have suggestions how to fix it? This phone model seems to be the only one with the issue. So it definitely seems like a phone model problem and not anything i can control. Any suggestions?
This problem boiled down to the processor (MediaTek) being used in combination with the theme being used for the application. At least that was the only thing that was found different across the supported phones we tested.
The theme for the activities were changed:
from #android:style/Theme.Translucent.NoTitleBar
to #android:style/Theme.Light.NoTitleBar
I developed an app for the iPhone that I would like to make for Android. However, because I was self taught with Xcode, I approached the project incorrectly. My app in it's basics loads a certain picture from a List View when the user selects the certain button associated with the picture they want. I had no programming experience when I started, so I just linked by drag and dropping roughly 300 buttons to 300 different scenes which displayed 300 different pictures in Xcode. Yes, it was very time consuming... My question is how should I approach my project to do the same function in Android Studio, but minimizing the amount of activities. I have the idea that it would be more beneficial to use code to have one List View activity that incorporates many buttons, that when pressed, will display the particular picture. Any recommendations for tutorials or videos as a place to start as I learn my way around Android Studio? Or am is it hopeless and I will have to have another roughly 300 Activities in Android Studio.
You can use fragment for acheving your purpose.
A Fragment is a piece of an activity which enable more modular
activity design. It will not be wrong if we say, a fragment is a kind
of sub-activity
Fragment you can think of it like a sub activity, which sits with in
an activity and which contributes its own UI to the activity screen.
Fragments are always part of an activity. With out an activity, a
fragment will not exist. So your fragment life cycle will always be
affected by activity life cycle. An activity can contain more than one
fragment. Similarly a fragment can be re used in multiple activities
Below links will help you to know more about fragment and how it's implemented in an android application
https://stackoverflow.com/a/13757241/4247543
https://www.raywenderlich.com/117838/introduction-to-android-fragments-tutorial
https://www.tutorialspoint.com/android/android_fragments.htm
https://developer.android.com/guide/components/fragments.html
My Android app essentially converts a website to a mobile application. The design is as follows:
Navigation Drawer containing the different categories of posts as per the website.
Each option is a different activity. I designed a BaseActivity (with the Navigation Drawer initialisations) from which the other activities extend, so each activity has the Navigation Drawer. (I do not use fragments)
Each activity calls a JSON parser to load posts from the website and hence takes upto 5 seconds to load.
The problem is that activities/screens once opened do not stay in the memory when called another time.
For example: Home Screen --> Category 1 Screen --> Home Screen causes the Home Screen to load a second time and hence takes up an additional 5 seconds.
How can I keep the full (or at least partial) instance of at least 3 activities in memory to avoid this nuisance?
I do call super.onCreate(savedInstanceState) but each activity restarts from the beginning.
For example: Home Screen --> Category 1 Screen --> Home Screen causes the Home Screen to load a second time and hence takes up an additional 5 seconds.
Add appropriate flags to your Intent, such as FLAG_ACTIVITY_CLEAR__TOP, when going back to the "Home Screen" activity. Among other things, this will bring the existing "Home Screen" instance back to the foreground, rather than creating a new one.
How can I keep the full (or at least partial) instance of at least 3 activities in memory to avoid this nuisance?
Your problem is not whether they are in memory. If the user visited them before, they are already in memory. However, without flags on the Intent or attributes in the manifest to help control matters, each startActivity() call creates a new instance of the activity.
So, first, you need to decide what the navigational flow of your app will be, particularly in terms of the BACK button, to decide what existing activity instances can be reused.
Second, you need a more effective caching strategy, rather than just storing stuff in individual activities. That way, even if you do wind up creating new activity instances (to keep the BACK button flow the way you want), those activities can retrieve the data from a cache, rather than have to reload the data from the Web site.
I need to develop an application which contain these tabs shown in the image. Each tab contain a form which will be filled by the user.User can switch to any tab.
User click Activity1, Activity 1 gets displayed and user enters some data; then user press Activity 2, activity 2 gets displayed, user press Activity1 again, Activity 1 gets displayed with the data entered by the user(not the blank activity).
At the end when user click "Save" I need to get all the data from these activities and save it somewhere.
I have worked a lot in java but new to android, I am stuck in developing the UI for this scenario. However I have done this many times in iOS.
Anybody please share your experience of developing such UI.
Thanks,
Fragments will be more suitable for this scenario, the benefit are
They are light weight and faster
Managed automatically by the FragmentManager.
Data Sharing between Fragments is smoother and simpler than it is for Activities
They don't complicate the Architecture of the Application
You can have as many Fragments as you want in you Activity. Following two links can be useful for you.
A similar Thread
A Good Tutorial
Another good tutorial
If even after that you decide to use Activities, You need to think
Are there any patterns on how to handle UI Transitions in Android Activities vs Fragments? I am currently looking into a UI that has at most 3 columns in Landscape.
I would like the UI to start with 1 column all the way across the screen and then on selection of something move in the second column and then on clicking on something in the second fade in the 3rd on tablets and phones and fade out the 1st column on phones.
I am wondering when I should do this as an Activity transition and when I should just use Fragments with Views that Appear. As far as I have read fragments can be moved over to other activities so my choice is either implement Activities with static column layouts that then transition taking the fragments with them or have one Activity with all 3 columns and have the Activity manage the Appearing of the Fragments. Both approaches could work but I was interested in pros and cons from as many angles for both solutions.
There are two questions similar to what I am asking but don't quite answer mine
Two panel UI with Fragments vs Separate activities
Android Honeycomb: layout problem - hide/show FrameLayouts
Fragments can seem like more code up front (since you're putting a view in a fragment, and a fragment in an Activity, instead of just a view in an Activity), but they're great at saving you from headaches in just this kind of situation- Definitely go with Fragments. They even handle the transitions for you.
We have some sample code called "Honeycomb Gallery" you can take a look at here, which has a two-column-plus-actionbar layout, and the ability to show/hide the leftmost column. This should give you a good head start in figuring out how to do layout for multiple fragments and show/hide them.
FYI, one important trade-off to using multiple fragments in an Activity instead of multiple Activities, is that fragments don't directly respond to intents - For instance, if you had a note-taking app where "View Note" page was an Activity, and you changed it so that there was a "view note" Fragment inside the main Activity, then you'd have to set it up such that the main Activity received a note ID AND a note action (create, view, edit, whatever) in the Intent, as opposed to just having the "view note" activity receive the note ID in the Intent. The main Activity would then need to set up the fragments on the page accordingly. Not a huge deal, but if external accessibility to various parts of your application via Intent is important, then it might be easier to break your app out into a few Activities, as well as use fragments to represent the individual components.
Based on the page The Android 3.0 Fragments API, an Activity is stand alone while a fragment can be though of as as a mini-Activity, which must be hosted within an actual Activity.
It goes on to say that the introduction of the Fragment API gave the android developers the opportunity to address many of the pain points developers hit with Activities, so in Android 3.0 the utility of Fragment extends far beyond just adjusting for different screens:
I think that using a single activity for an app is not necessarily a wrong decision, just a matter of style. It is a decision that you should make based on what you are trying to accomplish.
However, the introduction of Fragments was seen to solve real world problems. Based on that alone, I would recommend that you writing some "Proof of Concept" code and evaluate the results. At this time, this may be the only real world test that will matter
Use Activities for Full Screen
Use Fragments for Part of or no Screen (but not a service)
In my main application, there is on-screen tabs in a horizontal scroll-view I wanted to persist across multiple sections of the app. Sections include
News,Photos,Videos,Schedule etc. All single-user focusable tasks.
The main Application that houses it all is a application, and the tabs are just a view which call the fragment Manager.
However, I use Activities for complicated user activities deeper in the application. E.g. if someone plays a video, views a item detail page and the photo-gallery/slideshow sections, because they are all full screen components.
There is no need to show/hide fragments when transitioning to full screen because the activity stack handles everything you want to do it quickly and easily, and keep your code minimal and clean.
So I have Activity -> houses fragments -> launch full screen Activities for special commands.