iOS Question Background App Refresh feature.

[sergiones]

Hello guys.

I have a big problem here, reading this forum a lot and cannot find a solution. I use B4A about 3 years and had no problem at all. In fact I did this same project on B4A very easily.

My company has about 50,000 customers, each one can choose between 1 and 300 products categories. When a new product is released, I need to send a message (push notification) only for those customers that selected the product category. That's it, very simple! So, for a product I can send 10 notifications message while others needs 48,000 notification messages. I have all the server side running perfectly.

On Android I got a service with a timer and a Job. "Server, I'm Customer_X, do you have updates for me?" Killer shot, no battery difference at all.

On iOs after long days reading, I realized that Firebase notifications may not work because I cannot update groups so easily. I would need 300 groups and 1,000 updates/day. I'm not sure if I can send 48,000 messages individually either.

I'm trying to figure out an easy way to do that, and I found this:

http://www.macworld.com/article/302...e-of-ioss-background-app-refresh-feature.html

Is this a new resource? A new way to do this? If iOs cannot do this task or the firebase is already this solution, please, what do you recommend for me to accomplish this task?

Thank you very, very much!

 

[sergiones]

With "I need to send message" I mean "I need to send push notification". Sorry for my english.

 

[Erel]

You should use push notifications for this.

Whether you use Firebase or not is up to you. There is no limit to the number of groups or messages sent.

 

[sergiones]

Thank you Erel. Is it possible to send - let's say "random" 48,000 messages at the same time using Firebase?

 

[sergiones]

The idea was to send a silent notification when a new product is released for everyone that installed the app. At the function called by the notification I use the job to check wether that specific user must be adviced about the product. Is this a better solution? Thanks.

 

[tufanv]

You could register the users to be advised to a different firebase group like instead of ios_general you can register those users to ios_tobeadvised and you can send the msg to that group only.

The idea was to send a silent notification when a new product is released for everyone that installed the app. At the function called by the notification I use the job to check wether that specific user must be adviced about the product. Is this a better solution? Thanks.

 

[Erel]

Is this a better solution?

I don't think so. It is better to filter them in the server side. As tufanv wrote you can subscribe them to many topics based on their selected categories.

 

[sergiones]

Thank you guys but I'm afraid that managing an external group may become a trully nightmare. Let's assume that "Category 1" has 12,000 users today. Tomorrow it may be 36,000 users.

The users changes their preferences each two-three days, and new users are added about 120 a day.

How would this management be possible?

 

[tufanv]

Thank you guys but I'm afraid that managing an external group may become a trully nightmare. Let's assume that "Category 1" has 12,000 users today. Tomorrow it may be 36,000 users.

The users changes their preferences each two-three days, and new users are added about 120 a day.

How would this management be possible?

Why nightmare ? You will just use one line of command like . firebase.subscribetotopic("topicname") or firebase.unsubscribefromtopic("topicname"). Firebase will manage the groups for you.

 

[sergiones]

I will give a try Tufanv, thank you.

 

[sergiones]

I don't think so. It is better to filter them in the server side. As tufanv wrote you can subscribe them to many topics based on their selected categories.

Erel, assuming my initial idea of getting push notification for all the users and make a Job to check whether that particular mobile may be alerted, why don't you recommend it?

I mean, keep track of 50,000 users doen't look a good idea. I'm on Basic since 1985 with Hotbit MSX, C, Clipper, VB-Dos, VB6, VB.net and many others, I have literally +100 developments and I never saw a "third-party database" be error proofing.

First of all, if my server gets busy for some reason (yes, I know it should not happen but nobody can be safe that it do not happens), so firebase may not be aware of any changes made by the user. Firebase database is one, my server would be a secondary source. I have lots of examples that points it as a bad solution, for example off-line (local) CRM databases.

Yes, I can handle errors or even build a windows service to constantly check for changes and verify Firebase users consistency. But all the possibilities points to a lot of work, heavly server tasks and still be passive of any kind of errors.

Thinking as simplicity and error proof, it's very clear for me that sending the push notifications to all the users and check at this moment with a Job if the user may or not be adviced is a clean, easy and error proof solution.

Erel, I really know you are a legend at programming, I would love a reason why I should not apply this solution.

Thank you!

 

[tufanv]

You are asking to Erel , he will probably answer your question but i will share my experience with silent notifications with you.

I worked on silent notifications with httpjobs2 for over a week. Tested many many times. I was checking the users gold membership vdata and if they were not gold member anymore I wanted to send notifications. As you said, working with the firebase db were hard at this point. I needed to check my own database for the gold membershpi end dates and if they ended I wanted them to receive the notifications. This has many handicaps according to my knowledge. First of all , many ios users love to double click on home screen and close the apps they don't use. This will cause your silent notifications not arrive and many of your users will probably not get it.

Another problem is, ( some users also experienced it, there was a recent topic about it) When I tried silent notifications with httpjob, Some times I have received the notifications but sometimes i did not altough i did not close the app manually with double click on home screen. According to my experience %70 of the notifications are arrived by around %30 did not. ( I want to point out that, Erel says it must work so maybe my code and the other users code at this post : https://www.b4x.com/android/forum/t...f-app-is-in-the-background.76029/#post-483427 were wrong and that was the reason. But if the code was wrong , I think it should be different that getting the notifications on random basis. At the link I have provided, schimanski quoted a apple post, maybe that is the reason i don't know )

These are my experiences. Hope you can find the best for you.

 

[Erel]

I agree with tufanv. iOS gives higher priority to standard notifications over silent notifications:

https://developer.apple.com/library...l#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG23

If your notification payload contains the content-available key, your app will receive the notification if iOS or OS X determines it is energy-efficient to do so. If the energy or data budget for the device has been exceeded, your app will not receive any more notifications with the content-available key until the budget has been reset. This occurs once a day and cannot be changed by user or developer action. This throttle is disabled if the app is run from Xcode, so be sure to test your app by running it from the device to have the same user experience your customers will have.

This point alone is enough to prefer to filter the target devices in the server side. In your case it sounds like it should be quite simple as you just need to subscribe or unsubscribe from the relevant topics.

 

[sergiones]

Tufanv, Erel, you are absolutely right. This Apple "inconsistency" seems to be very known in many places. My solution would lead me to lot of errors, exactly what I'm trying to avoid.

Thank you for sharing your experience guys, sorry if I sounded annoying.