I'm planing some kind of information app for android and I'm not sure what technical design is best (because this is my first real android app).
The app which observes the latest information from an server consists of 4 screens:
Main screen -> shows the information (consists of a thread which updates the information by server push)
Configuration screen -> you come here from main screen if you'd like
to configure the information type you want to see.
message screen 1 -> you come here from main screen to send new messages to the server. The screen consists of a radiobutton list where you have to specify the type of information you have to send.
message screen 2 -> You come here from message screen 1. Here you can type the messages and send it to the server.
My thought is either using 4 Activities each containing one view or using just one Activity which contains a ViewFlipper of these 4 Views. What is the best approach and why?
Activities have their name for a reason. Each "action/activity" should be placed in a seperate activity. The user want's to configure something? Send him to the preference activity. The user wants to take a picture? Send him to a photo activity. And so on.
Therefore I think you should have 3 activities here when you split this by actions:
Main screen (user activity "read information/messages")
Configuration screen (user activity "change preferences")
Message screen (user activity "send a message")
For the last one you could use a ViewFlipper if you want to split the sending into two different layouts.
What advantages does this have?
Well, first of all you don't have a big ball of code in one activity that handles everything. Certainly that's possible, but can get somewhat ugly. Maintainablility here.
Also remember that we are still in a mobile environment. Yes phones are really powerful these days, but they still have very short run times on battery. So don't waste battery when you don't have to. Which would mean in case of one giant activity that everytime the user wants to send just a message, he has to load all the other stuff with it. Unneccessary code executed -> unneccessary CPU cycles -> battery drained for no reason.
Apart from that it's convinient for you because the framework supports you this way. For example: the backstack handles a lot of stuff for you already, e.g. you don't have to manage all the back-key logic (you would have to keep track of the layout and the back key depencies otherwise).
If you want to make use of androids intent system for 3rd party apps, this is also very useful. You can control access to your activities on a per-type basis. E.g. allow other apps to call your message activity, but not your preference activity. If you have one big activity this becomes difficult, with some intent extra parsing just to determine which screen the other apps intents to display. And that's propably the biggest reason why activities are activities. Apps can work on a action-base with each other.
Related
I'm used to HTML development. Now I'm starting to program my first Android apps. In the tutorials I have read it looks like Android development favors using a new activity for each different form.
Nothing-less I think it's quite possible to use a single activity and use the setVisibility(View.VISIBLE|View.INVISIBLE) to show / hide GUI forms elements (This is much more similar to what I'm used with HTML-AJAX).
Is there something wrong with this way of development in Android?
Using a single activity(process) also allow to use singletons to share state and data between GUI components, while the multi-activity requires a "slightly" complex communication system using extra data to communicate the selected id, ...
I wonder what are the disadvantages of the single Activity "pattern" and why no tutorial/manual on the Internet use this technique to develop Android apps.
Do fragments have any advantage over showing/hiding views when I have no intention/interest to reuse the component?
Approach : Single Activity :
This approach will show/hide UI elements based on user interaction with app. Showing a UI Element draws View hierarchy starting from that element. This is called Layout Pass. This layout passes are expensive operation when performance is calculated. This is not advisable way to implement.
Approach : Single Activity, Multiple Fragment :
This approach will also have Single Activity but multiple Fragments associated with this activity. Each fragment defines new UI screen based on application requirement. More details available : Android Developer Guide : Fragments This is much advisable way to implement your requirement
I think there is nothing wrong, but depending on how complex your app will be, the source code can easily become very confusing!
Do you want those code happen:
elementXScreenA.setVisibility(false);
elementYScreenA.setVisibility(false);
elementZScreenA.setVisibility(false);
elementXScreenB.setVisibility(true);
elementYScreenB.setVisibility(true);
elementZScreenB.setVisibility(true);
And then, maybe after that:
elementXScreenB.setVisibility(false);
elementYScreenB.setVisibility(false);
elementZScreenB.setVisibility(false);
elementXScreenC.setVisibility(true);
elementYScreenC.setVisibility(true);
elementZScreenC.setVisibility(true);
No. I don't want to do that !!!
That just base on your ways for funny. There are many many disadvantages to do that, and I don't think there are any advantages in this approach. I can list some. Any comments will add to this list:
Design UI. How can you code multi layout on one xml layout file? Android Studio doesn't support this. You will see elements overlap elements
Performance. Load all your application UI is not an intelligent way. You lost memory, lost CPU. Although you set invisible, your memory still store those information, and when transition between elements, invisible elements still count into.
Maintainable. I'm working with a medium project, and still headache every day with bigger and bigger fragment and activity. (in case that each layout for each activity/fragment). How does everything become when you make all your layouts into one activity?
Collaboration. All layouts in one file. All your application in one file. How can you can collaborate between members? Code conflict, wrong edit ... Noooo. Stop that :)
No. Stop that. You just make element invisible when that element need this. For example, floating button when user scroll down list, error message textbox when no error need to show, ...
I wanted to learn more about the Android Services / Broadcasts, so I started a simple project, to create a battery monitoring app. It turned out pretty good, I'm using it for a few days now, but I want to add a new function: to show since when is the phone charging/discharging.
First I thought that I would create two static fields in my BoradcastReciever extension class, where I get and publish the data about the battery, one for the actual state (charging/discharging), and one for the time, when the change in state happened. This way, I could just subtract from the current time the last change, and know exactly since when is the phone charging/discharging.
But there is a problem with this solution: It won't show the correct data at first, when a user starts the app. I wouldn't make a big deal of it, but I saw that Android tracks this data somewhere, because inside my phone settings I found this information, so why take the hard way.
So my question is: is there an easy way to get from the Android system the date/time (no matter what format) of the last charging state change?
I looked at the BatteryManager reference but there are no constants named after what I seek, and which I could use, to get the information from the Intent of my receiver.
The Android OS tracks the connect/disconnect of a power source, but does not make this data accessible to apps. You have to record this all yourself, using intent filters.
The two intent filters to use are android.intent.action.ACTION_POWER_CONNECTED and android.intent.action.ACTION_POWER_DISCONNECTED; with these, you can monitor when the power source is connected and disconnected.
You can find information about this process explained incredibly clearly here. Another blog describing the process can be found here.
I want to do in an Android application what I can do very easily in a "common" Java application : in a function triggered by a click on a menu item, I want to display a modal dialog box in which either the user can enter a text or choose between two or three answers (typically "yes", "no" and "cancel"). Once the user has made his input, the function can continue according to the choice made.
With the Fragment class, I can display the dialog box. The problem is that it only appears after the completion of the function triggered by the user's click. This means that the code depending on the user input has to be executed in the class derived from the Fragment class. And this has two disadvantages :
- it's more complex because a communication between the two objects has to be implemented,
- the reuse of the class is not easy since it's customized to communicate with only one class. Of course, it's possible to implement multiple communications towards as many class as we want, but the complexity will be even worse.
Is it possible to do what I want to do in a more simple way?
Thanks in advance for the time you will spend trying to help me.
Using a modal dialog is not allowed in android applications due to reasons like
A phone could go unattended for a long time. If a modal dialog pops up in that time, the app will be blocked, until the user attends the phone and dismisses the modal dialog. This will amount to loss in valuable processing time.
Even when the user is operating the phone, an app should not be blocked as a phones hardware configuration is far less than desktops and every millisecond of processing time is important.
I may be missing other points but these are the important ones.
So you should consider using callbacks to continue processing users input.
Maybe try to use http://developer.android.com/reference/android/app/Fragment.html#getActivity()
I have something of an abstract question regarding managing live feeds/polling on web sites.
I am creating a web app (built on Java/Spring/Hibernate) and on the user's home page I want a live feed of the latest activity from all the members of there team, and I am trying to work out the best way to handle this query on the server side.
The brute force way would be to load the current users list of team mates, and then iterate through each of his team mates, loading their latest conversations/file uploads/etc, and then merging all this activity in to a single list sorted by timestamp and returning that (lets say for sake of example that we just return the top 10 latest activity for the feed).
However, that seems very un-performant, especially as this operation would need to be done regularly (depending on the polling interval).
I have also considered making all the potential activities (conversations/status updates/uploads) as extending an Activity class and then just having a direct SQL/JPQL query in a DAO that selects all the latest activity from a set of users to be returned, but concerned that might bypass the caching and continued access to the DB would also reduce performance.
Has anyone handled this type of problem before? any one know what a good approach is?
Thanks!
This is an old one now, but here is what i did for this:
All tasks that should appear on a live wall extend Activity (this was already the case)
Created a new Notification object, the Notification had a link to the underlying Activity and a link to a user (who was being notified).
Created a pre-persist hook for Activity that created a Notification object for the Activity being persisted - it did this for every user that was interested (all users following the user that was persisting the Activity)
For the moment, Notifications are persisted/retrieved to the DB - possibly not scalable to very high volumes, but the approach I think supports moving to a Queue based system (such as LinkedIn's Kafka queue library which is designed exactly for this purpose). As it is per-user, it also provides the option to have a read/unread notification flag for significant notifications.
This has probably been asked before, but I can't find a good way of implementing it. I'm trying to write a program that manages a form of messages, and these messages are received from an external data source. This all works. However, the problem comes when I try to notify the user: I would like to have the notification jump directly to the message when it is touched, but this seems to mess up the back stack. This is probably best explained by example:
I open up the message list, the main activity, and browse for a while.
I hit home and go into another app (let's say Music).
A new message is received. A notification comes up, which I touch. The message detail view is displayed.
Now I hit Back. What I want to have happen is that I return to Music, but unfortunately, Back sends me to the message list, and then hitting Back will return me to music.
The both the list and the detail activities are marked as "singleTop", and the exact flags that I use for the notification Intent are:
FLAG_ACTIVITY_NEW_TASK
FLAG_ACTIVITY_CLEAR_TOP
FLAG_ACTIVITY_SINGLE_TOP
I figure if the Messaging application can do this, why can't I?
I have found one way to do this, but it's still not ideal:
Change the detail activity to have a different task affinity from everything else.
Add android:launchMode="singleTop" and android:excludeFromRecents="true" to the detail activity's manifest entry.
(Optional) Modify the list activity to open the detail activity with FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET. (This makes the task more like the built-in messaging app.)
The only fault to this scheme is that switching back over to the app will always go back to the list activity, but at least it is consistent. If someone else has a better way to do this, I'd love to hear it.