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.
Related
I hope this makes a bit sense, basically, I have this feature in my app for tracking calories which consists of having this page that only appears the first time you use the feature and it asks you to add personal details (so it can make the right calculations), after that you get faced with a simple page that tracks your nutrition with a button for the user to insert the meals he has eaten, this page has to save the inserted data (via firebase) and then restart from 0 each and every day.
my first problem is I don't know how I make the page that only appears one time to save personal data(to be more precise I don't know how to make only appears the first time). and the second problem is how do I make the app automatically sends the given data at the end of each day?
interface in normal state, interface when adding the meals
hopefully, this 2 images will help you get a better grasp of what am trying to explain
don't worry am not looking for someone to straight up solve it all for me, I just need some orientation about what type of things/functions I need to do to solve these 2 problems
While #Narendra_Nath's answer might work, please note that is not a bulletproof solution. Why? Because a SharedPreferences doesn't persist across app uninstalls. This means that your user can install and uninstall the app and see the page as much as they want. So if you indeed want a user to see a screen only once, then you should consider storing that data in a database. Please note that SQLite isn't also a solution because when a user uninstalls the app, everything that is stored locally is wiped out. So what's the solution?
The best way to solve this would be to store the data in the cloud, either in Cloud Firestore or in the Realtime Database. So you can set a boolean variable and always check against it.
If you however intend to implement Firebase Authentication, then another solution would be to display the screen when your users are authenticated for the first time. So even if they will try to sign in on another device, install and uninstall the app, they won't be able to see the screen again.
Regarding the second problem, you should consider using Cloud Function for Firebase. It's the most elegant solution. If you want to somehow schedule an operation, then you should consider using Cloud Scheduler, as explained in my answer in the following post:
Is it not possible to have a code in the background who will be called every 24h?
Make the page that only appears one-time -> store a value in the shared preferences "isInfoShownToUser -> false" then do a check when the app starts to check if this value is false or true. If it is false show the "take the info" page .. then turn the value to false in the shared preferences.
How do I make the app automatically send data -> Use a Workmanager implementation to send data to the server (Firebase) at a particular time ..
Or use a implementation like the first one which uploads the data to the server just once everyday
If I have a class that contains a static variable, say x:
class MyClass {
static boolean x = false;
// Other methods
}
Now let us say that, hypothetically, I set x = true; from my first activity. Is there any point through the rest of my app's life cycle (including various activities and threads) where this value will simple be 'reset' back to false due to how the 'Google JVM' or the android environment works? I have heard that static variables have a 'lifetime', that dies when the program dies. Do Activities count as separate 'programs'? What about services? Or even Widgets?
I am asking this because it is often difficult to share complex data structures that rely on other complex processing (like syncing data from an online database) in android due to how 'separated' activities are, and static variables are often a very quick and dirty solution to the problem. Other things I have tried include serialisation, but that doesn't really seem like a practical solution either (constantly serialising and decoding objects when the user navigates from one activity to the next seems like it would be very resource intensive).
If I am an evil person for doing this, please tell me what I am doing wrong, or even better, give me some links or examples of better ways to solve this problem.
Yes. There are times where that will reset. Primarily if the user leaves the app and starts fiddling around with other apps or if the user lets the phone go to sleep for a long period of time. The Android process could kill the actual app. Then the "state" of the app will be restored when the user comes back, however static variables will be at their defaults because the actual process was rebuilt.
Generally passing small objects between Activities and Services is done by overriding the Parcelable interface. This will allow you to save and restore objects using setOnInstanceState methods of both Activities, Views, and some adapters. They will likewise, have a restore method in which you can rebuild the object. Parcelable is preferable over Serializable.
Larger data may require a shared file or database depending on the data that you want to have synced. There is a 1 MB size limit for parcelables being passed between Activities. One common tactic is to save the information to a file and send a URI to the location of where the information can be retrieved.
Answering your question - yes, there is a situation when you set x = true and value will be 'reset' back to false. Well, not exactly reset but consider this scenario: you have an activity and a service. Service is using separate process (you can define that in AndroidManifest when you declare your service). Then those two processes (main app and service) won't share memory and setting x to true in your activity won't affect the value of MyClass.x in your service. In all other cases changing value in one place will be visible everywhere else. Hope it helps!
No, a static variable will not be changed unless you change it or the app ends, it is safe (but generally unclean) to use it. Closing the activity the variable lives in won't hurt it.
You suggest you just need to keep track of a value as you move around activities. In that case you can add the value in your Intents as what is called an 'extra'. If you need to also pass back the value after, android also has the startActivityForResult feature
Intent extras example:
x below could be any type of value including any object which implements Parcelable
Intent intent = new Intent(...);
intent.putExtra("myKey", x);
startActivity(intent);
in receiving class:
x = getIntent().getBooleanExtra("myKey");
Edit:
Given your additional comment - "lists of objects that contain yet more lists of objects" you may get a Parcel too large exception when trying to use extras, but this is an indication you have a bigger architectural problem and that there may be a better approach
Use Gson.
Gson is a Java library that can be used to convert Java Objects into their JSON representation. It can also be used to convert a JSON string to an equivalent Java object. Gson can work with arbitrary Java objects including pre-existing objects that you do not have source-code of.
You have two options. Convert to string , then put data in an intent then pass to activity. Or Convert to string with gson, save to a preference, then in the other activity, check if the preference is alive and read from it.
If you wish to be bold, you can persist to database preferably using Realm for Android or ObjectBox is a new mobile object database optimized for performance. With ObjectBox, we are bringing technology from NoSQL server databases to mobile.
I have to implement custom search in my application for android 2.3.I have some EditText in which user type one letter and then I send response to the server, retrieve all the results matches this one letter and then I need to display them in a list. When user types second button I also need to send new response and refresh data and so on.
The question how can I do this in Android 2.3? What should i use?
This seems to be too open ended with too many questions to give a really helpful answer.
What you use in your app will heavily depend on how the server's API is expecting you to communicate. I, for one, am all for hiding the specifics of what a server does from the application and put all the "smarts" behind the API. So a query like:
http:/blah.com/getresults?search=a
would result in whatever matches 'a'. If it is searching a MySql Db, processing a Google search, or accessing files on the system doesn't matter.
Your code needs to worry about the interface to the API to make queries and processing the results, whether they're free formatted text, JSON objects, or whatever.
Maybe rewording your question or provide information on what you know would help.
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'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.