On Tue, May 10, 2022 at 10:48 AM Joel Winarske <joel.winarske@xxxxxxxxx> wrote:
1. Will Toyota at some stage provide a virtual device for testlab?Can you be more specific?For high volume consumer electronics, product validation is always handled using physical board farms; pre-launch and post-launch.
[Bern] Part of Firebase \ Release and Monitor - testlab is the same as it used to be just AVD (virtual) but is now mostly physical and there are several test types. This is a paid service and since we don't have any money, we use it sparingly. We have our own automated white box / instrumentation tests but use testlab robo for black-box. They're constantly offering new make/model/release whilst deprecating the old, all you do is upload your .apk testlab read's your build/manifest then present appropriate devices capable of running your app, you choose which you want and away you go, test results are very comprehensive. AGL may only have a dozen boards at most so from app/dev perspective easy-peasy, emphasis being on board provider and Google
2. Something to take back to your managers will Toyota require access to Firebase - "personally i think you do, a fine balance between managing your interest whilst protecting user privacy".I think the Database choice is dependent on the overall system design. Personally I would look into ObjectBox, ObjectBox Sync, or create a Rust shared module (loaded via FFI). For Rust my colleague has open sourced a Rust crate called Membrane. It auto generates Dart code from Rust code, zero copy, supports asynchronous green threading, and is *very* efficient. Synchronous support is nearing completion. https://github.com/jerel/membrane[Bern] firebase is much-much more than a database every flutter dev is going to use it , it also has great services OEM's can benefit from, else you have to reinvent it.
Concerning local storage I was under the impresion Flutter ObjectBox doesn't (at least yet) suport web, at this point we attemtping to be as flexibile as possible and chose localstore. Yep totally agree overall system design, also on local commit we asynchrounous push local changes to pumped.backend (nothing to-do with firebase) this is for DR and when user buys a new vechiles etc, that on app uninstall "right to be forgotton" we zap all user data local and remote. Anyway I'll talk to the boys again refer ObjecectBox.
thankyou for membrane, ffigen, and glucodium links, and need some small time to digest, i have friends/colleagues working in different domains of automotive
ffigen is another approach for creating Dart code from a C header. It's a basic solution, involves more Dart work, and not as sophisticated as what you can do using Membrane.
https://github.com/dart-lang/ffigengluecodium is also another option HERE is using:My understanding is that ffigen and gluecodium are not as efficient as the Rust Membrane solution.3. Before I get much further along I'll need to know what your expectations will be for flutter app developers, we can then in corporate it and build an AGL flutter app baseline policy requirement thingI think it's all relative to the system you're integrating into. If you have a paying customer - they would drive this. If you are targeting AGL to showcase at trade shows, then you would want to have the best performance on a given platform. In general good performance on less hardware is the name of the game. Flutter can outperform QT and Web/_javascript_ in regards to system RAM and responsiveness, with less Engineering NRE; if done correctly. It's important to start developing in-house expertise on a couple of platforms. Understand how they work, how designs scale/perform, etc. It will help to direct design decisions. I've seen some really cool products get designed on desktop, only to fall short on platform hardware (mostly Web/_javascript_). Desktop and limited resource hardware runtime environments are two different universes. Your design needs to be stable, and run well on the lowest limited resource hardware that you plan to market/sell to. Another important aspect is testing on a loaded system; never trust an unloaded system to represent the end user experience. So the general expectation is that AGL Flutter App devs have experience with limited resource hardware environments.
[Bern] Yep i hear you and certainly don't underestimate the challenge or overestimate my chances of success, i can budget 1 trade show thats it so will be early next year and need to secure a partner/investor else i'm in trouble.
Also whilst we're spit-balling, Pumped MVP connecting Drivers with Merchants starting with fuel, is a B2B, flutter being the all important presentation in the chain, and I cannot see how this model will work without a business relationship with vehicle manufacturer, (i have EV and telematics colleagues watching from the sidelines see if/when I crash and burn).
If I ran a car company I certainly wouldn't let anyone (startup or other) run a B2B app on one of my vehicles without a business relationship.
i would also think very very carefully before getting into the business of managing the deployment and rollout of those apps in my cars, I'd be looking to one of our other AGL members having deep tech gravity well to step up else's Google and Apple are going to do it all
cheers
Bern
_._,_._,_
Links:
You receive all messages sent to this group.
View/Reply Online (#9823) | Reply To Group | Reply To Sender | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [list-automotive-discussions82@xxxxxxxxxxx]
_._,_._,_
