In-app messages work well in test mode, but seem to be very unreliable in production. I made campaigns with "Modals" as the message layout. The simplest possible messages, without any pictures. If I set countries as the targets, no messages seem to be shown in the target countries.
I have 2 campaigns without any country targets and those messages get shown, but still just sometimes. The first of these campaigns informs the user they have an opportunity to reach Level 1.
The message get shown about 50% of the times it should be shown (once per device). Sometimes the message get shown so quickly that it just flashes by, so it is impossible to read the text. It closes before the user closes it. The second of these campaigns inform the user when they have reached Level 1. It is the same result as described above here.
My calls to logEvent are from methods, which are directly called from the onresume method in the Main activity of the app. They are called according to certain conditions, not every time onresume is called. My calls look for instance like this:
FirebaseAnalytics.getInstance(this).logEvent("gyro_access", Bundle.EMPTY);
What can be done to make the In-app messages work in a reliable way in production?
I got this to work now. I used this method instead to trigger the messages:
FirebaseInAppMessaging.getInstance().triggerEvent()
I also updated Gradle, so the latest version of com.google.firebase:firebase-inappmessaging-display was used.
So the solution to my problem was either using the triggerEvent-method or updating Gradle.
Related
some one suggested this but i am not able to implement it can any one can help me by providing the desired code in kotlin..
Another solution can be to call
UsageStatsManager.queryEvents
with the start of the day as first parameter and the current time as end parameter and then filter the results to check just the
UsageEvents.Event.SCREEN_INTERACTIVE UsageEvents.Event.SCREEN_NON_INTERACTIVE
events
take the timestamp of each of them and sum all the time passed between each
SCREEN_INTERACTIVE -> SCREEN_NON_INTERACTIVE
events, this would easily show how much time the screen was interactive, so screen on and the touch enabled.
There is a possibility that you'll have a SCREEN_INTERACTIVE event that doesn't have any related SCREEN_NON_INTERACTIVE, this is when the
UsageEvents.Event.DEVICE_SHUTDOWN
event happen, luckily this event is in the same list returned by the queryEvents method
remember also to declare and make the user to allow the android.permission.PACKAGE_USAGE_STATS permission as stated here
ps. i haven't used this yet but looking at the documentation it's the right thing to use, probably the one used by the android settings pps. look also to the other events in the same package, they might be helpful to what you want to accomplish
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
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 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.