B4A Library AppUpdating - automate apps updating from a webserver

Important note: since all the changes made to the Android OS the original code is to be considered outdated. Thanks to @Yayou49 you may find at post#290 a version of the class usable on Android 6+ versions.

Note: version 1.25 breaks existing code so, please, read changelog in post #60 below.

Hi all,

this is my first contributing lib to this great NG.
How do I dare to publish such a low-grade stuff in an area where generally you may find real masterpieces of programming? Well, to be honest, I hope in your help to upgrade my work to a status of "ready-made solution" for those who prefer to run their own webservers where to publish apps.
Secondly, I was asked (both privately and publicly) to overcome my legitimate embarassment and go on with the publication. So, here we are: AppUpdating 1.18!

Note: any valid code fragment comes from some other thread, while all the bad stuff is entirely mine ;-)

Please find attached both the library as is (yes, it works out of the box) and its source code.

On a following post I'm gonna describe the lib in greater detail and show how to use it.

Umberto

AppUpdating version history

* version 1.30 (read notes on post #228)

• compiled with okHttp 1.01 and okHttpUtils 2.20
• removed files for version 1.25

* version 1.26 (read notes on post #84)

• added property WebChangeLog to read optional app's version changelog data
  
• better management of versioning in the info file
  
• removed files for version 1.18 to avoid confusion (still available on request)

* version 1.25

• too many to list; see post #60 below

* version 1.18

• initial release

 

[udg]

Hi Anser,
thank you for your post.

ApkUpdt.CurVN returns a valid value only after a call to ApkUpdt.ReadCurVN; it's the latter which calls _UpdateComplete (with status OK_CURVER or ERR_NOPKG).
If you look at the code from my AppUpdateExample you find:

'STEP 1: which is apk's current version number?
'Can be called at any time not necessarily as step 1 as shown here
Sub btnCurVer_Click
'Read version number of currently executing apk
apkupdt.ReadCurVN 'send out command; async result in update_UpdateComplete
End Sub
....

Sub update_UpdateComplete
....
Select apkupdt.Status
Case apkupdt.OK_CURVER
EditText1.Text=EditText1.Text&"Running apk version: " & apkupdt.CurVN&CRLF

I like the idea of an optional progress bar as an alternative to the similarly optional waiting splash screen.
It's time to schedule for a much due lib's update, I suppose...

udg

 

[opus]

When talking about an update,
here are the changes that I made for me.
The original code shows eror-messages if the website is not online. IMHO there is no difference between no update available and the website is offline. In both cases the user can't get an update, why show him an error at all? I just skipped that message.
A change which I plan to do is make the appupdate deselectable. That would be done outside the lib, however when an update is coming and the user denies the installation, this could be deny could be save as a setting. That way following unwanted updates won't bother.

 

[opus]

Is it possible to detect wether the user has canceled the update?

 

[Harris]

Is it possible to detect wether the user has canceled the update?

Don't know about detecting Cancel when receiving an update, but my solution is to periodically update a table on my server with the App Version Number of each device in use. If a problem (or missing feature) is reported, I know what version they are running.

 

[opus]

My question was aimed on the lib. Would the the app which is using the lib be able the detect the event when the user cancels the update?

 

[Harris]

My question was aimed on the lib. Would the the app which is using the lib be able the detect the event when the user cancels the update?

As I believe, this is calling an intent. Your question is can it provide you a response (event raised)? Yes, no, maybe - Frankly, I don't know... (However, like you, I wish it could).
Baring the answer is NO, I was offering an alternative suggestion to your problem... Did user install update - and if not (or never received an update) - which version are they currently using?

Capish?

 

[opus]

Thanks for the input. However I'm aiming on the usage or not usage of AutoUpdate. If a user cancels an update, he might not want to update all. In this case I would present the possibility to deselect the settting "AutoUpdate", which would skip the update on further runs of the software.

 

[udg]

Hi all,

I'm following your posts about intercepting the user action about installing the eventual update or not. After briefly googling I wasn't able to find OS-related functions/events suitable for that, but this morning I woke up with the following idea.
Since launching the update request and restarting the app following an update are two distinct phases and the delay between them is usually very short, you could use a timer. Just start it soon before the intent for updating is executed and after 30-60 seconds or so check whether the user accepted the update, looking at the version number. Then the app could use that info in any way like not asking for updates anymore or repeating the update request only every few days or any other that may fit the needs.
What do you think? Could it be an acceptale solution or is better that I sleep a bit longer in the morning?

 

[opus]

Thanks for this Input.
I started a similar question on that in the Questions Forum and was just thinking how to formulate the same idea in english as a reply to Erel.

 

[opus]

Erel did give me a good hint. Look in here: https://www.b4x.com/android/forum/threads/how-to-get-result-from-startactivity-intent.60262/

 

[Harris]

Getting closer but no cigar (as of yet).

In any event, you will need to record and inform yourself that app was NOT updated (since Android has not mastered the Telepathy sensor yet).
We know when the appupdate check was made (since we called it).
Prior to checking for new, what was the current version?
If new version is available, what is it's version number?
After the download session, and potential restart - what is the current app version?
Same as first check? Then Cancel was pressed.

You will likely need to save old ver to disk since the app will reboot (when updated).

You could also put a nag screen asking user to update - or simply finish (close) the app claiming old versions are no longer supported.
All depends on your requirements.... In my case (commercial product for a paying client) - ALL updates ARE required.

This is basically a repeat of what UDG stated above...

 

[opus]

Looking closer into it, the Problem can be solved more easily.
What happens if the user accepts the update, in this case the new Version will be installed. During the Installation the running old version will be killed!
Since I'm looking for the situation when the user doesn't accept the update, the running old Version will not be stopped nor will the version number change.
So all I have to look for is the Activity_Resume event after an update, if it happens the old Version is running (i.e. No Update done!).
So I need something that tells me that the user was asked to confirm update, this is done by the library using in _UpdateComplete Event! Setting a boolean to true if the correct Status is reported and checking this boolean in the Activity_Resume Event does it all.

 

[MbedAndroid]

i'm facing some issue with "app xxx" has been stopped.
Somehow i'm thinking this is coming from this lib.
I close the lib with StopService(newinst2)
but is there more to do to exit a background service?
note: i dont use the automatic check on app start, the user has to enable it by clicking a button.
But some activity is started i noticed checking the logs

 

[opus]

Hard to say without the code. If your logs show that an automatic update was tried although no user input was made to start it, check or show your code that initialises the app-update instance.

 

[MbedAndroid]

no code is inserted
as said the user has to start the updater
Still if you look at the debug log, you see that this lib starts activity

and i close this service at exit
so i wonder why this service is started even no command is given

resume
** Service (newinst2) Create **
---- AppUpdating.NewInst2: service created
** Service (newinst2) Start **
-- AppUpdating.NewInst2: processing service_start

 

[MbedAndroid]

no code is inserted
as said the user has to start the updater
Still if you look at the debug log, you see that this lib starts activity

and i close this service at exit
so i wonder why this service is started even no command is given

resume
** Service (newinst2) Create **
---- AppUpdating.NewInst2: service created
** Service (newinst2) Start **
-- AppUpdating.NewInst2: processing service_start

 

[MbedAndroid]

i inserted this in activity resume
it seems to help
dont know why it was started in activity resume

        If Not(IsPaused(newinst2)) Then
        StopService(newinst2)
        End If

 

[udg]

Hi all,

the newinst2 service is awoken by the OS when any app is updated; then the service checks the just-to-be-updated app and goes to sleep if it refers to a different app than the one it's linked to. All that is due to the way implicit intents and intent filters work.
May the above explain the debug log as seen by @MbedAndroid?

 

[MbedAndroid]

hi udg...
its explains exactly what i found, every google play update the b4a app came with this message
can we do something about this? some check?

 

[udg]

Hi @MbedAndroid and all,

time ago I planned a new branch for AppUdating based on the explicit intent mechanism, but unfortunately I hadn't enough time for it.
The idea is to get rid of the manifest filter and activate/disactivate the filter on OS app updating only when needed.
It's not difficult but it'll take some time. Maybe in Xmas time ... ps: read it as a good intention not as a promise..eheh

udg