I’ve had a look at react native too and I agree with @joshuef
Although, if one would like to try it out @tmark’s explanation is on point 
Setting up a RN native bridge project is available in their docs too:
3 Likes
You make a valid point.The reason behind the minimum API level of 24 is the use of newer features of Java (in this case CompletableFuture) to provide good developer experience. CompletableFuture is currently supported by API 24 and above and Android has not yet provided a support library for backwards compatibility.
There are third-party support libraries that do so, but personally I feel that it’s only a matter of time till it’s official. This would bring down the minimum API required to include the Android library.
Yes. That is correct 
One advantage of using this package would be that it supports native development rather than a cross platform solution. Here’s an interesting comparison.
9 Likes
Yes the point was not so much meant for now in alpha stage, but more so for later on when we are running release candidates and obviously the OSes will be at a later version than they are now.
But a point to mindful of as development reaches an advanced stage of the “product”. The older the OS/platform that SAFE can run on will better for a lot of people out there.
In Australia we have groups taking old computers, cleaning them up and giving them out to students/families who cannot otherwise afford computers for school work. The OSes on them are usually old since that is the OS licence that the computer originally came with. Still XP for many of them.
7 Likes
We are most definitely keeping this in mind and will continue to do so. Thank you for pointing out it’s importance
The API level 24 and above is only for native Android development using Java/Kotlin.
The C# package mentioned supports development for devices with API levels 16 above. This might be something for you too @happybeing
13 Likes
Shared medium article in r privacy, r cyptocurrency and r opensource
12 Likes
Yes, this was the main thing I was driving at. I understand we can route to specific nodes with Crust and IIRC, there was talk of having WebRTC via Crust too. Connecting the dots, I would have thought we could have some genuinely useful mobile comms apps even on alpha 2 or 3.
It would be very cool to have genuinely useful and secure apps for voice/video calls and (online) messaging.
5 Likes
Can you guys elaborate on this? I’m pretty unfamiliar with this whole area, trying to learn, so I’m curious. I’m a seasoned software engineer though, so it’s the specifics of this situation I’m ignorant about. Thanks.
@tmark and @lionel.faber thanks for the ‘bridge’ refs.
3 Likes
To be precise, the poc mobile authenticator is built using Xamarin. We picked up Xamarin for building it to support iOS and Android by managing a single source code.
We have only one mobile authenticator package which is built using Xamarin. As you rightly said, irrespective of the language/framework the developer chooses to build the mobile app, the authenticator should be able to work seamlessly until the expected IPC standards are followed.
With this release, we have an android library that could be used to develop native android applications. The applications would be compatible with the latest version of the poc authenticator. We were not able to support the older poc version, because we switched to base32 encoding for the IPC messages. Also, the poc authenticator now supports all authorisation requests, while the older version was only supporting the basic auth request.
6 Likes
Yes indeed. There is a SAFE fundamental that states:
Clients are software programs that allow users to connect to the SAFE Network. There will never be charge levied by the Network if messages are sent directly between two Clients. However, any indirect messages that are sent between Clients that involve travel across the Network will carry a cost.
However, this direct messaging is not in the scope of SAFE Fleming, but it will definitely be a part of further pipelines.
10 Likes
This definition covers the whole thing.
In simpler words, to develop a react-native cross platform application for SAFE, will need a react-native library which takes JS calls from the app and these in turn will call natively defined functions for each platform. And in the case of SAFE, by ‘natively defined functions’ it means FFI functions in Java / C# / Objective-C that in turn call functions defined in RUST and compiled for specific platforms.
4 Likes
I have installed LineageOS
on my ancient phones. It works fine and I always have a new version of Android.
6 Likes
Thanks. That I think I understand, and according to the article I posted one of the reasons RN performance is slow when it hits the hardware (on mobile).
I don’t see the bridge as a ‘complexity’ issue for the app builder (it is just an include). Perhaps naively, it looks to me similar to creating ffi bindings for a new language, which I think Maidsafe have got fairly streamlined now. But maybe not?
The benefits would be re-use of core application specific code across web app, desktop app, and then to mobile, plus any useful nodejs and general JS libraries.
Against this we have code size which seems significant, performance as mentioned, and ‘additional complexity’. The last one is a bit of an unknown to me, so I’d like to understand that part better.
4 Likes
Yes. Courtesy of the ffi_utils and safe_bindgen crates
The additional complexity here will be the development and maintenance of the react-native library itself. The APIs exposed by the Java and C# libraries are one-to-one APIs exposed by client libs, whereas the JS APIs are high level with a layer above SCL. The developer will have to understand all the external APIs to manage/maintain this library and with the existing cons this seems pretty significant too.
3 Likes
So the complexity you and @joshuef refer to is related to maintaining the React Native bridge itself, which I presume only needs updating when the SAFE client libs change - is that roughly it?
Can you explain how this differs from what we have in providing the SAFE NodeJS API, I think there’s more to this than I understand so far?
Thanks!
2 Likes
This is correct.
The NodeJS / Java / C# bindings to expose APIs are generated using safe_bindgen. In the case of the React Native bridge the update will need to be done manually for each platform and then for the bridge itself. Down the line this could probably be scripted too, but we’ll have to wait for RN cross-platform support across mobile and desktop to stabilize first. From what I could find, some of them are still experimental.
3 Likes
I agree, you are pointing out a very important and valid use case. Still at least the chat setup would require a PUT.
However I can also imagine, that in the future ppl will be more intersted in handling the whole conversation over the SAFE Network. I can also remember a comment from Maidsafe (I think it was David?) that as soon as the secure messaging layer is comleted it might enable an option to transfer push notifications/messages through the network which are not persistent (no PUT). I found this very exciting and would be my preferred option when it comes to ‘direct’ messaging via SAFE. This in exchange would of course require both participants to be online.
9 Likes
It’s been about a month, has anyone made any cool test SAFE apk apps yet?
Java isn’t my speciality but looking forward to getting on this when I can.
Perhaps a good first app like “SimpleSafe” desktop repo we used to have for JS, would be a good start.
Still looking forward to getting into this soon
5 Likes
As @whiteoutmashups asked at the start of thw week…
Has anyone got any wee Android DApps they’d like to show off?
I wouldn’t imagine they have to be particularly polished or even particularly complete at the moment but I for one would like to see what sort of thing people are working on. That being said if you are developing something on the hush-hush then feel free to keep the details to yourself.
Also, if you are struggling with anything then let me/us know.
David.
7 Likes