Android-DFU-Library
Android-DFU-Library copied to clipboard
NordicSemiconductor
Same API pattern as iOS
Hi there,
We are trying to integrate the DFU firmware update feature into our application on both Android and iOS.
But it looks like the API of the Android and iOS are different, as iOS one is only applying the delegation for callbacks, but the Android one needs to provide the some activity (related to the UI) and use the service.
Can we make them to follow the same pattern, as we want to try to write same business logic code to integrate them, and want to follow the same UI flow?
Thanks,
Dante
Hello @zcufo123,
The Android DFU library was created long time ago, and back then we were focused on ease of use. By integrating a Service it's enough to call initiator.start() and the DFU will start and finish even if the app went to background. Since then a lot has changed in the Android world. There are ViewModels, JobScheduler, IntentService is being deprecated, Kotlin, etc. We have now the Android BLE Library, which didn't exist back then. So had we started today, the lib would have looked differently, but it is how it is.
On iOS there are no services which makes implementation easier, but still, I see plenty of possible improvements, e.g. making it independent from transport layer, which now is heavily integrated.
What we could have done, and what we did, is to make sure the public API is similar. In both cases you have the DfuServiceInitializer with similar methods and properties to some extent, you get similar events and progress updates. On Android you may disable the notifications.
We will not be rewriting neither of DFU libraries, as they have thousands of little fixes here and there, which are fixing little issues and make it stable. We had dozens of feature requests from the customers to handle their corner cases and it would be very difficult to include them all in the new and library. For Zephyr-based project there's McuManager library which was written in a better way, but it undergoing another refactoring.
Hi @philips77
Thank you for your reply.
The API is looking similar if the notification is disabled and the thing that makes me happy is I don't need to provide an activity to get that notification.
We are following the multiple fragment + one activity pattern, so it is annoying that we need to provide some other activity, it will cause more job to deal with the navigation, but now it looks good to me if the notification can be disabled.
To be honest, what I want to say is to make the lib to be light, now it is using a lot of component, that you can avoid it, like service and notification, from my understanding what the lib need is just threads and the bluetooth interfaces, also the callbacks.
The more thing you are using, the more trouble you may get when you maintain it, and actually it is responsibility for the people who integrate this like me to work on how to use it (like applying the service or not).
Anyway, it works it is good now.
Cheers,
Dante
We are following the multiple fragment + one activity pattern, so it is annoying that we need to provide some other activity, it will cause more job to deal with the navigation, but now it looks good to me if the notification can be disabled.
The purpose of this activity is to bring the right activity to the front. Have a look at our example in nRF Toolbox: https://github.com/NordicSemiconductor/Android-nRF-Toolbox/blob/master/app/src/main/java/no/nordicsemi/android/nrftoolbox/dfu/NotificationActivity.java But if you don't need notification, there's no discussion.
To be honest, what I want to say is to make the lib to be light, now it is using a lot of component, that you can avoid it, like service and notification, from my understanding what the lib need is just threads and the bluetooth interfaces, also the callbacks.
True, but by integrating Service and Notifications it is also much easier to start for beginners. But you're right. Today I would have done it lightweight, like McuManager lib.
It looks like the McuManager is something I want as it is handy and tiny.
So can I use FirmwareUpgradeManager (https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager) to do the same thing as this DFU library?
They use completely different protocol. McuManager is compatible with devices running nRF Connect SDK, Zephyr and Mynewt, while DFU is compatible with Nordic SDK. So the choice of your stack determines what upgrade method will be used.
Currently we are using chip nRF52840, it is good to apply the McuManager? The chip SDK that we are using is from: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52840/Compatible-downloads#infotabs
Nordic has 2 very different stack for this chip: nRF5 SDK (which is now in version 17.0) and nRF Connect SDK, which is based on Zephyr RTOS. They are very different. If you have started working on your fw or already have a solution on one of them, it will be difficult to migrate.
Also, a short info: https://devzone.nordicsemi.com/f/nordic-q-a/62423/should-i-use-the-nrf5-sdk-when-developing-for-nrf52840-or-should-i-use-nrf-connect-sdk
Still a little confused about which one I should apply, and I think they should have decided to apply nRF5 SDK. So in this case, I only can use this DFU library? Or I can also use nRF Connect Device Manager and FirmwareUpgradeManager?
No, you need to use DFU. nRF Connect Device Manager is a clone of MCU mgr.