#FlutterInProduction | Observable Flutter #58

[Music] hello everyone and welcome to the final observable flutter of 2024 and also the final component of flutter in production our yearend Showcase of the state of flutter in large production apps around the world and I'm excited today because I'm joined by guest from some Regional brand names some Global brand names who are delivering digital experiences to their customers millions and millions of customers with flutter and we just we're I think gonna have a pretty great conversation today and we do have uh my dog who just won't leave my side today so we're we're we've got some special company um but before we get started just remind everyone that this is the flutter community and we're here to be great to each other today chat is off for today's live stream so being nice to each other should actually just be easier all right let's begin so the first person who's GNA join today is Santia from Sofi Sano would you like to say a few words to introduce yourself sure yeah hey everyone my name is Satya I'm working at a a company called Sofi Sofi is a fintech company which has products in banking invest it's like a onstop stop and that's why the mobile experience is very important for us uh I I'm working as a a tech lead staff engineer at Sofi been here for a long time to see the transition ex to share my um Journey with you guys great okay well I look forward to hearing more about that journey and transition uh shortly all right next joining from Swiss air uh Swiss Airlines software or Aviation software you'll have to clarify for me is uh Barett so hello I'm bar rostaa I'm from Swiss Aviation software um we are a software vendor which is very specialized we build software products for maintaining and operating aircrafts my role yeah maybe my role um I'm the um head of system on architecture so like a tech lead great yeah and you reached out your Swiss as reached out to Google back in February to have a little collaboration and and help talk about flutter and that highlighted for me because your app is is B2B so it's not in the open app store and and mechanics and Airport hangers who are working on planes are are using this app yes and that's a kind of thing that we just never know exists you know unless you would said hello so I'm really glad you did okay next guest is dongyong Le from LG dyang would you like to say a few words to introduce yourself yeah um hi uh my name is dang I work on application Frameworks on y TV uh currently uh my focus is PL and I also work on a react based web application framework called Ina uh previously I worked on web standards and so uh my perspective would be from embedded software development and we uh work on our own platform web and also I'm am originally a web person so from web perspective oh nice a fellow web to flutter developer that was my path as well all right the next guest for out of five we'll eventually fill this panel and start talking about stuff is cha Tai from Walt which is more of a European name I think than North American so chaai would you like to introduce yourself yes hi I'm chaai I'm flood competen at Vault also a gde for flutter and dart so Walt is a company local Commerce platform and we are active in 28 countries over 500 cities but people in States might probably be more familiar with door Das because vault is door Das International uh so it's connecting people who want to order anything from food groceries flowers games and other items with people who want to sell and deliver them um as I said I'm flood compet s but also I'm a full-time senior flutter software engineer all right great and longtime acquaintance of mine okay lastly we've got Gary from Virgin money Gary welcome to observable flutter would you like to introduce yourself hello well I am Gary I'm from Virgin money we're a UK bank Full Service Bank in the UK serve a few million customers across here and I'm based in Glasgow and I'm responsible here for our digital engineering and our custom identity platform so digital engineering is a bit more than mobile mobile web and some of our microservices Java bit responsible for that at the bank and ready to get go cig all right great so yeah yeah you were just teasing some of your backend stuff as well that we'll we'll certainly get to later some of the questions that we were able to pull from socials and other questions that even just the flutter team submitted because the flutter team also wants to know what different aspects of flutter development are like at companies of your scale uh touch on those kind of things but first question is just what was your journey what was your Road like adding flutter to your Tex stack obviously if you already have an existing codebase it's a big decision you can either have the clean break you can do ad to app if you haven't yet done different crossplatform that's its own kind of additional distance to the leap of faith so I'd love in whatever order I'd love to hear just some thoughts from from you all about your journey to add flutter to your text dexs sure yes uh I can go first um so we started this journey more than five years ago uh when flutter um was pre- null safety um we we did there's a mobile C uh Sofi X team which did an experiments on various platforms available at the time and we landed on U flutter mainly because of the user experience and how how easily it was able to you know get two code bases at the same time and get minimal functional like like stateful uh like we could we could see the easy things uh done very fast um but that was 5 years ago we took a long time to do the actual fully flutter app the way that we my approach it is through a add to app approach so we we have for a long time we had the so flutter as a module and we used to embed that into both Android and iOS apps and ship those apps um but and sofa is a very very big company like we had more than100 per tust the code which does did the migration uh from native code to uh flutter and it took a long time uh to touch all the surfaces and figure out the bugs uh and actually do the features along uh in both the code bases um yeah and recently uh like in 2024 uh the initiative was to get off even though 100% flutter we were still using the native as the rout uh for a long time uh that is not ideal and our build times are not good our app size is not good um it's also three code I mean we before that we did a monor repo get everything together uh that was a 2023 initiative and 2024 is to get actually out of that and we still have the mon repo but flutter will be the route so uh yeah that's there's been a lot of a lot of exploration and and thinking about that specifically on the flutter team as well in terms of that last bit the the entry point because you do have the the glue code between native and flutter looks different if you run flutter create and your all flutter from the beginning which of course is still like all flutter apps are like add to app a native of course they have to exist within a native app versus if you have kind of a fully featured app first like you had anyway even as you migrate feature by feature you get to that last thing where you have to flip this bit and it it feels tricky one thing we've wondered and I'm I'm curious about your thoughts on this and then everyone else as well would it would it ever make sense to almost think about this in Reverse where instead of adding flutter to a native app you actually add native to a flutter app and then that could be the first step and then as you move feature by feature once you convert the last feature to flutter you're you're just you're all flutter now and you of course have like a layer cake there of native flutter native as you're going what what are your thoughts on that so we talked about it uh that was one of the initial Explorations and also doing a parallel app uh of like both native being uh shipping shipped and we are developing INF flutter but organizationally doesn't make sense like you want uh something that is shipped and you need to get real customer feedback on things that uh people are using so we we can't switch in place I don't know how that would work like uh we we are having one binary going to the App Store and uh I don't think that would have worked out yeah gotcha um okay so uh looks like chaai you also have some thoughts on this oh and Gary as well yeah so um our company is quite large and our tax stack is quite wide and we have react native app we have flatter app native apps Progressive web apps so like many kind of um front end site different Technologies so um our domain is very Dynamic we need to be really fast to deliver value to uh market and sometimes we experiment uh and sometimes like we take the decision which might not make sense but for MVP and validating the idea we just need to connect pieces for example we connect uh some parts from the Native apps some parts from flut app and then make a totally brand new app so different kinds of combinations and flexibility here is really important so it can be add to app so add flatter to an existing app at flatter to a native host just a native for example Android app or native IOS app so you just need to be smart and understand how pieces can be connected to each other and that's called system design to be more efficient fast and flexible yeah being smart that's the hard part uh Gary so so we actually looked at that Craig of we've actually got two main apps and so I should have said them when I'll do my intro I'll talk about that so we actually said could we put everything in one app binary so basically take both apps put them in one with the new flut stuff and have a flut shell from day one with the apps embedded but because we had two apps that would have meant we were two apps on Android and iOS we had four variants of that to manage as well as continuing to keep making those apps run and improve them so the management and maintenance of it was going to be a nightmare um and just Tak kind of technical complexity a few of our really really good Engineers got it getting all of our team on board and understanding that was just it was too risky we were worried we make mistakes along the way yeah there's a lot of a lot of layers a lot of architectural recursion instead of you know algorithmic uh Baron you said you had some some comments about some flutter web stuff playing in yeah just to pick up your your question to U maybe um embed into flutter that is basically what we did um we came from a pure desktop Vault and we were a little bit late in the app game I would say uh the airline industry is a little bit slower moving than it's not consumer Market it's not fast-paced um and at that point we said we had already some Mobile Solutions in place but they were fully only web and we got complaints that they drop connectivity they are not stable enough and whatever and at some point we decided okay let's bring this into real apps um and that was um 20 21 and uh we looked at that and we looked at what we should build this on iOS and then on Android and there's even some customers with Windows no no we will not do that so we skipped the whole native thing at all app wise and went directly to flutter um so we have not a super long experience but we are from day one flutter H um and at that stage we decided okay we want to replace our web uh mobile solution into a native flood rep and it has hundreds of screens so it takes very long to have the same thing in flatter so what we did we just basically embedded oh sorry um the um web screens with web views in the flatter app as menu entries of course it comes with downsides the look and feel is a little bit where you where you have to sacrifice um no nice animations and all these things but it worked quite well yeah I imagine users can feel when they Venture back into the the pure web portion of of the app but can't let perfect be the enemy the good as the English idiom goes so there was um you had mentioned there the part of your the friction that you had leading into all of this was connectivity in a pure web based app for and and you you said this in person when we met back in February about there maybe not being great Wi-Fi in an airport hanger or it's actually on a local network and so there's there's also some pressure there with uh with flutter and that is my segue into this next question so we got this from Dominic online and he asked are your apps offline first or at least offline capable what strategies do you use to synchronize data maintain schema migrations cue actions and expose failures to users and if you're thinking H that is a very detailed question it seems like this person has thought about this before they have they've given talks about this and they're interested in how you all have approached this problem with flutter uh our app is a fintech app so we don't have a offline strategy like we need our data to be perfect like we have talked about it but it doesn't make sense you need it to be real time yeah I guess that makes sense it's like stale data is you know worse than no data yeah like we don't want I mean if you are no internet we don't just want to stop it like we don't want to have an offline and we will be liable for things so yeah that makes sense okay I can go next so offline thing is really cool cool good but it also brings complexity so when giving some decision you need to really think about pros and cons is it okay to have complexity because you really want the app to work just do the job uh when you introduce this offline thing there will be some things that you will spend a lot of time to figure out and fix uh so sometimes you need to compromise from this additional value and real time is really important particularly in our domain for example our app is used to uh prepare orders when multiple people are preparing orders we really need real-time communication so but at the same time uh our uh people picking or preparing orders that are working in sometimes these warehouses uh so there is not sometimes internet so we need to be prepared also for this so it's always important to listen to customers to see what kind of challenges they have and uh to make the correct decision to support offline or not we currently not support but depending on the feature requests uh we can support it yeah that certainly I think it's important to acknowledge so not only you know for Sofi it's just actually a bad idea always but even if it's a good idea it's going to be a lot of Engineering in that question all of those components go into a serious offline imple you know strategy implementation synchronizing data maintaining schema migrations because you're going to have that cache data on the device but now the schema has changed and then you need to queue actions because you wanted to save some piece of data but you're offline so yeah it's a lot of engineering work uh Gary I think you also have more yeah so we are similar to satu we're um you know real time making sure everything's up to date kind of has to be for a bank we did explore one of the first things we looked at in flutter actually we we probably fail love a little bit too early with it was realm sync so we were looking at caching so we weren't necessarily offline first we were looking at a caching strategy with realm sync um it just became a bit a little bit too complex for us to kind of fit that in with an existing Bank in architecture and kind of lucky we didn't go down that path given they deprecated it fairly recently as well so we fell in love with it they deprecated it um so kind of glad we didn't yeah I was I was really sad to read that that was deprecated because realm has incredible two-way uh two-way syncing and then then you know bought them and and yeah that was that was s it was really good yep and uh uh bar yeah so um actually that is exactly one of our use cases for one of our apps we have one app which is a technical lock book which is basically an app for the pilot to track all the technical issues he has before flight and during flight and of course that's a scenario where you cannot rely on connectivity they have to even actively turn it off while they start and land um so so that is a super complex question so um basically my message is don't do it if you don't need to Don't Do It um and the other message is you need to design it in straight from the beginning if you say let's do the app and we build it in later you will have a very hard time um how to do it basically is very complex but we um synchronize we write to a local database and we have written an own synchronization layer from that a complex past which we struggle a lot with um to synchronize then uh all this information to a down stream application server um here it's important to track your changes in a way that you can later on the server pick them up as a stream and validate everything there you should not merge everything into a document on the local client and just send a big bunch down and the server says yeah but okay what has even changed so understanding that the server needs to have a fine granular change lock or change stream that that is important when you do something like that there's also Solutions on the market which just do this for you um and if you can spend that money I think it's not that bad to use something which is really specialized in just solving this problem um I super agree with that the amount of engineering yeah time those those Solutions can save you yeah absolutely maybe the second part is a different question how to cover the case when the schema changes and for us it's a little bit um yeah different because we have a special way of deploying the app um it's not via the public app store it's basically yeah consumer not the consumer app but just for business we build one version of the app from that moment on it does just gets Buck fixes nothing else and then we will release and we do this every six months a new major version of the app which may introduce new features which may change the database schema and then you have to synchronize everything down to the server uninstall the old app install the new app it's basically a new app each major version is a new app you pull down again all the data uh and it will be feed into the new schema of the new app um so we basically don't have that problem by using this trick to say okay each major version is basically a new app yeah and you have very very unique constraints there around selling this airplane maintenance app to Airlines who then don't as you were just alluding to they don't follow any kind of typical end consumer app upgrade path of like oh there's a new version I'll just download it it's a whole thing the whole company moves in lock step so you have people using lots of different older versions of your app yeah yeah okay next uh dongyong Lee wants to also share a little bit more and I I left the question of the the journey to flutter too early so yeah D le would you like to tell us a bit about how LG made the decision uh yes uh in uh in we uh most applications are based on the web web is really great in terms of uh development product productivity uh thanks to the reactive paradigm like react but uh we tried really really hard to optimize the application performance and we managed to make it reasonably fast but uh uh with uh complex optimizations and we couldn't make it uh really past so uh we always wanted the technology uh with both good uh good performance and good productivity that's why uh we thought about plat uh we started thinking about flut back in 2021 uh we noticed at the time that flutter was really promising so and uh because we uh we tried really hard to optimize Real Performance we knew why web was slow and we realized that flutter solved those problems so uh we started on experimental project in 2022 so the first thing we did was pting flutter engine to web uh and and then we wrote a sample application and the application performance was good and more importantly uh each memory usage was much smaller than web so uh we started a real pilot application uh TV Guide for Japan um the reason we chose that application was because uh it was used only in Japan that means uh it didn't involve much internationalization work uh that uh a big uh technical problem for us and also uh because it's a pilot project uh even if it failed uh the impact wouldn't be too much uh there is the reason we chose the application and uh the development was really not 100% uh smooth uh but uh finally we succeeded and uh today uh WE TV sold in Japan have the flutter TV Guide application so it's in in production in the market and we are really uh happy with the result and we are currently working on mobile applications uh this year and next year uh we will have a flutter for key applications in for Global Market not only in Japan I'm super excited about web OS bringing flutter apps to an enormous additional pool of screens because obviously IOS and Android have long been able to run flutter apps and the browser and everything but monitors and and TVs and just kind of casual games or or and you know actual meaningful apps as well that people seriously interact with um I think that is just a a really exciting new kind of Frontier for flutter and a pretty compelling value ad as well because I think a lot of folks have already kind of internalized and understood okay yeah iOS Android two code bases versus one two code bases I know versus one solution that I don't that maybe has some I don't know what someone's route to the hundreds of millions of LG web OS screens in the world is uh other than than this so I I personally think that's super exciting yeah so uh not only uh not only new product uh because we upgrade uh the software for on old old TVs so those flutter application will go into old TVs too gradually all right yeah you're back filling to 20 TVs going back to 2021 or 2022 uh I I don't exactly remember but uh if I remember correctly we we upgrade uh TV for five years okay okay well yeah that's a lot that's a lot of screens and thinking about the the different form factor of TVs and web OS is maybe a segue for this next question bit lighter maybe a bit just kind of whimsical all answers here are are valid I'm curious what each company you know what you've each kind of gone with here how much do you customize your UI and ux for each platform so obviously iOS Android have their own idiomatic things that they think are how the phone should behave and they're not always the same and then you've got copertino you've got material some companies don't use a single Pixel of either of those some use some so I'm curious just for each of you and then also thinking about form factor with TVs how much do you customize this you know how does it work for you all well I can start then um so delivery of everything has been a very ambitious Dynamic and exciting domain so it's very competitive and you need to really make a difference when you are competing in domain and how you can make the difference is the look and feel when your users use the app so our company has a really strong brand identity identity not only for like the UI component but also the motion and uh some really cool animations uh usually uh we are really heavy for uh customer facing app which is native IOS and Android but the flut app which is Merchants are using so uh we also have this our strong uh company identity and in our company we have a design system team which provides every platform uh some design tokens UI components uh some guidance about how to give this and I think flutter suits best if you have your own design language uh rather than trying to fit in I Android and iOS uh because as Eric sidal says I always love this quote so platform wants us to build platforms but we want to build for users and we want to give our identity and yeah as as Vault not as Android or iOS of course it's important but our design system team is clever enough to give this correct Solutions so we don't try really hard to fit in iOS and material style things but we give our own identity yeah I'll just jump in as well so we um when we made the decision to go down the Ro 18 18 months ago roughly I think we started three three main decisions we had there was loads right but the three main ones I would say had to be amazing for our customers um and a number of reasons one one it leted to look good one it had to work and three it probably had to be quick to change and adapt and get stuff to them when they wanted new things um number two was it had to be secure and number three we had to be confident we get actually Engineers to do the work may we talk about the last two later on Craig but from the first one from design point of view we um we built our own Library so we built our own widgets basically so we've got our own toolkit maybe 50 components I think either extensions or versions of kutino and Android but they're built for ours our our design system um we did that very early doors one of the first things we did was to build that out um and it's really paying paying back now and we've got a design system in place for all of our widgets all of our screens are now templated so if I'm developer and an engineer I've got go and build something you're literally picking from a list of stuff and it and it just builds um and you've had Lucas on recently from widget book that was an awesome tool taking a pick up early on so thank you Lucas and it was actually going back to how we got to flut origin Leah who obviously was part of the team we just reached out randomly to Leah for help early on and she was incredibly incredibly useful and getting us going and we still kept in touch we still do occasionally kind of look at flutter flow um to bring it to life I think if we get a bit tighter integration with flutter flow and our kind of own hosted UI components in there I think you've got something really really cool around how you could build build that out nice that's cool sorry if the name drops name drops okay yeah yeah I know I mean name drops are great both Lucas and and Leah still super active you know obviously neither at Google Leah was neither currently um but yeah both super active in in the flutter world and I I don't think mind did um SAA hey yes so for us um flutter one of the reasons we went to flutter is for the unified design system language and it is harder to do it on the native platforms so with flutter which is one code base and designers can say this is the design language that we're going for and we have something internally called Pacific Design system which is based on top of material so there is not customization much per platform level but our widget we have okay big widget Library and now we even have an extension where the tokens are like assets are automatically created as code like there is a system in Supernova uh where we put the token there the designers do it they do the check in and it actually automatically transfers into our design catalog and then it developers can use it directly like uh it's a deeper integration um yeah uh uh just like was saying right like our design system has like hundreds of widgets we have a widget catalog and not much customization per platform we we do at some widgets level but the main problem will be with animate like back button navigations uh because Android things differently and iOS things differently so that's where sometimes we we get also into traps but um not much too much into that we s the same stue things like back button H toggles and switches we try and keep them they look native but they're hour versions of it they're trying to kind of get away from that uncanny valley where it just kind of if it looks a bit too off it can put people off yeah sounds similar to us yeah I agree that like the those really really lowlevel kind of leaf UI elements like toggles switches you know like maybe buttons but I think most companies have their own button designs as well um certainly I think it's a strong idea to go with the platform style if you invent your own switch or or checkbox it can look look a little weird sometimes uh okay anyone else on this or we have uh ready for the next question all right next question it is so Gary you teased something and then I pulled a question immediately for it you had mentioned security and the engineers working on the on the flutter app and it was that final part that I wanted to focus in on so for all of you and Gary you your mind may already be primed to talk about it what was your engineering team's experience like actually switching to flutter so we um like like I said one of the key decisions we made was could we get people we scaled in flutter we um we run a few experiments on kind of I can call and the competitors right the kmm the react Naes we ran a few experiments on it and the one that we found developers gravitated to quicker and adopted quicker was flutter I'm not just saying that from a spin point of view it's the one that they kind of they got quicker and when I mean developers I mean mainly Android and iOS guys and girls who were doing it so they picked it up really quickly so what we did we just bit of a prefer concept with a small team uh we kind of got a bit funding a PC and we kind of took develop of different levels of experience to see how quickly can they adapt to the kind of how how different is from Swift and cot and it was amazing at all levels the guys just picked up really really incredible and and we always kind of joked a little bit that everyone seemed to have fun they the old genu seemed to also enjoy it enjoy coding with it whether they were learning something or what they were delivering quickly was great and it was always quite good to see the Android guys deling an IOS app and stuff was pretty cool um we had a couple ners in the team who were like uh I'm an iOS da I been an iOS da for the last X number of years you do this I'm not going to have a job you know I'm going to get paid less I'm not going to have a job so we had to deal with a lot of that so there's a lot of winning hearts in Minds with a team and we did we had a kind of Simon who looks after mobile for me did a lot of of training coaching and and looking after the guys and we kind of gradually bought them all in and it got to that Tipping Point where we had more of our devel Vel opers working on flutter stuff than working on Native and that was quite a to day that you know they're doing that so now I'd say probably about 70% of our devs are now primarily coding and flutter we we're primarily using ad to app I should have said at the minute so we've got both apps we are building a new singular app that is a flutter top to bottom app but right now most of our works add to app so we build modular components and deploying them back in that can then be packaged up and put in you um but now I'd say it's great we we struggled early on to get H advice externally the consultany seen in the UK I don't think was as strong as it maybe is in the US um and abroad at the minute so we it was always quite hard to get experts to come and talk to us about what are the downfalls what are the good things bad things about flutter a lot of the stuff was out of date online um a lot of the opinions you would get so all in I think now if you come and talk to the team it's really good place we we review our of productivity and morale and stuff in the mobile Space is really good at the moment Sor that's a bit of a long answer trick right help other but I'm gonna go last so I think uh cha you're next and muted okay that happens often yeah so uh when it comes to tech radar our Tech uh in front end is quite wide as I mentioned but we support it uh sorry we at react native for example we decided not to continue with react native um so we have really talented so uh developers who are ready to solve business problems they are all very talented but when it comes to flutter it's also a bit a different feeling because uh there's always um some you know uh worries about if flutter is going to continue after five years what's going to happen with flutter is always there and we really need to build trust inside the company and to build trust we don't say hey trust me I know what I'm doing hey trust Google we just say hey uh we build trust this is the product that we have building it works fine customers are happy so yeah and uh our developers are also like uh ready to you know uh to react they're very proactive because Android and iOS developers they're fine they don't have to prove anything it has been there for years but for flatter Developers we really need to all the time prove ourselves because um crossplatform has better repetition uh and it's really difficult to change that and uh to do uh to change this I think you really need to have an evangelist in your company and in this case it was me who I was the flood guy flood guy and we were only two developers now we are in we are like more much more developers and we have now three GDs in our company this really great number considering that we are Product Company so I I want to mention two things here one is that um you really need to build trust internally uh to you know robust reliable application and then when you are active in the community you also show Community that hey we are building exciting stuff here join us and you get the best talent and then your the quality of the team increases and then you build quality stuff and again you increase the trust to the stakeholders so it's like internal stakeholders you get the top talent and then you continue all right let's see in the line that we're we've got here is SAA I believe hey yes yeah so for us it's a very polarizing uh to M to flutter uh we have like just like others were saying right like very staunch uh and expert I was an Android developers and it was a threat for them right like I mean we like you will be a beginner in a new language like uh you you don't have even though it's mobile development like the things that you were able to do so quickly before you would have to figure out and you would have to uh do them or probably get it from somebody else so uh for developers it was not an easy thing one thing that helped with developers is onboarding piece I think flutter is always good with the initial onboarding like the hot restart quick restart even if an add to app you can do attach um the developer tooling that was that was a first good draw like uh getting them trust that you know this works um and slowly we we haven't really seen any platform specific issues of the code that we migrated like there is code that is both ways and even for managers to right like I mean the code that they didn't migrate if there's a bug they had to fix in two places but if they migrated they need to only do it at one place and really didn't see any issues because of flutter uh like the only exception there is web use that's uh a different topic I'll get to that but uh we we I mean for I mean it is a slow progression I mean it took over years now we don't it was a decision to put like flutter in the job description too like there was some uh some we started hiring for mobile Developers for a bit now we officially say okay we are we hir the flutter developers yeah but it's a slow transition uh and I think now five years after this like nobody kind of remembers like okay we were scared at on one point yeah it's definitely an intimidating journey to start uh I'm still saving all my thoughts for the end here uh Burn yeah so um some experience from our side so we come from a from a different world um so we had no mobile experience at all not even knowledge um we have also a little bit a different set up so for us we have a typical three tier application we have a backend the database we have an application server and we have front ends and all of that is running on Prem on the customer side so basically the apps are directly talking to the customers application server so no cloud in between uh and we have a full um stack from the back end to the front end with uh full stack developers so basically the same guy creates the data Bas tables writes the application server code the apis and then needs to update one or two front ends the old one which is the desktop front end and now mobile apps um so basically what we did we did one week of training so they are all very well experienced Java developers we did one week of training for flutter and we said okay two months have fun play around and then we did another week of training and collected all the questions and all the doubts and whatever we had also some help from some experts which had already a little bit more experience here and that's it and then we said have fun developing apps and of course we also have a little bit of specialized team which is taking care of all the building all the deployment all the Automation in in in the back end so the developers not touch that they write their code they run it on their desktop if it's fine its feet there and then the the specialized team picks this up and makes a real app out of it um the feedback is great the people love it some of them don't want to go back to Java yeah in my experience changing Tex Stacks is like I won't I won't I won't I won't I won't and then you know until you do and it's all it's like idees too you know I was never going to leave Sublime Text and then one day I tried vs code and now I really like it uh dang Le yeah uh so uh to uh to to use a FL we had to learn a new language start but uh it wasn't really difficult I just uh told the developers to study and they studied themselves uh without uh without a problem actually uh they enjoyed uh learning a new language and so they liked it and uh they found that uh it was easy because uh they they were already familiar with the react so uh flutter is basically uh the same reactive uh Paradigm and uh one thing we liked was d uh has strong types and N safety uh we had problems in JavaScript uh because of types and N errors so we like them and we also like that uh linting and unit testing tools are built in in plat so um yeah it was easy to do those things um so uh flutter and D is uh themselves were okay uh the main difficulty was uh we didn't have a framework our framework at that time and uh our developers are used to using our web app uh framework or what we call inex so uh the the main difficulty was developing framework and widget set and application in parallel and um we are also working on internationalization uh these days they they are the difficulties that we have but um the language itself and um flutter itself was easy uh to learn yeah I think most people that go deep in flutter do find it quite easy to learn but that's cold comfort when you've been doing iOS or Android or web development for a super long time and you know you really like it and you know it and it's comfortable and I've absolutely been there myself so like I'm not pointing any fingers at all by the way remind me later I want to follow up with you about the localization friction that you've had something tells me that we could do something in the framework to make that less of a source of friction but that's a different conversation okay yeah uh okay any other any thoughts on this or are we ready for the the next question yeah one thing I kind of forgot was at the dot language self is quite new like nobody knew that before we started doing flutter so it was like we we were experts in like cotlin or other languages and there back and developers who want work cotland but getting into that and also it was not as matured as other languages right so U and there are some things that we just can't do and we surprised to learn um it was um uh I mean now I it's an easy language to learn but again it's a different language and it's not useful outside this context as much yeah and just just to kind of look back and just reflect on I spoke about that I don't like the single people I spoke about that one engineer who was really kind of negative at the start he he's awesome he's literally probably one of our most vocal Advocates um and he drives the teams he kind of leads a team in one of their areas and he's he's kind of went full circling last year he's awesome so he's went on that curve yeah that that reminds me of like a lot of the best I in my opinion a lot of the best team leads the really experienced Engineers who have been there done that I think a great quality that those folks often bring is skepticism of new shiny things promises that seem too good to be true so it doesn't surprise me at all that like this particular person you know maybe the tip of the spear on team was also like the slowest to be like yeah this hype train is real you know that that just seems totally natural to me okay Baron I think it was you you started to mention your full stack situation I know you have Java on the back end just trying to pick questions at segue off something somebody said and so the next question for everyone of course is are you using any dart on the back end and just so you know answers of no we are not totally okay we're not um I do play about with it in personal times so I'm have had to play with server code and stuff and I personally love it but you know we're a bank we've got to have our back end's got to be Enterprise grade right back I can't well Victor stuff looks amazing and and it works I can't hack about with something that's not been around for years at the minute on the back end for me so we we're we're Java back end primarily but all love factors same for us but we are using D for within the mobile app tooling like um within the monor repo now we are using quite a bit of tooling um for example now we want to collect the developer matrics and put it in data dog uh so we use Dart for that like anything within our Sofi mobile repo uh is Dart we are focusing on that but actually going to the back end uh yeah just like Gary we are back ftech we probably won't do that yeah I suspect it's probably oh no Baron you go yeah maybe it's the same for us we don't do it we don't use it on the back end but um I'm now sparking the idea internally to use it to replace all our scripts so a command line is from me the next SC yeah like Comm rappers like you do shout out to them and then yeah because it runs on Linux it runs on on Windows mic OS so it's all there now yeah yeah that's an interesting point the first thing that I worked on when I started at Google I was on the fuchsia team and my very first project was to overhaul a bunch of the automated testing bootstrap stuff that was just a jungle of bash scripts into a bunch of Dart code and fuchsia was was using a lot of Dart you know obviously everyone on this call is using a lot of Dart so that's kind of like a shared thing that everyone probably should have some proficiency with as opposed to deep bash knowledge which is you know pretty arcane at least for me so yeah that that certainly makes um a lot of sense any anyone else on this I've got plenty more questions all right next one have you found this one also coming from online our good friend Dominic have you found good ways of automated testing with Native features Bluetooth camera payments deep links using something like Maestro or browser stack or do you just go with manual QA hey yes uh I can go first for this um yeah for as I was a long time as dead and I was doing test automation quite a bit so uh this is a passion project for me but when we came to flutter we were Native and there is nothing three different Stacks like web use Natives and flutter there's nothing that can actually go across at the time there there was appm which probably could have done it but changing the context and being the keeping the test case reliable was very very hard um so we stopped on that and then started picking out up after we became flat first app now uh with Maestro we are able to do that like we are able to have a test case which logs into web view get into flutter screens and get get to the native screen like um we we have minor of native screens but still we want to be able to do like an end to endend flow of them and we are able to do that uh but you know these tests are high level uh they will be flaky so we are aware of that and we'll use them sparingly yeah some some native screens are just going to probably be unavoidable for a long time if not forever like Apple pay Google pay you know really really deep yeah yeah yeah if I can just jump into we we started off trying to use a lot of kind of out the box flutter Frameworks for this so either that and Patrol and stuff um we tried to get it so it was working we've went back to using browser stack and we've got that working quite well now um just that very similar to stue I think having web views native and FL was it was just a bit too complex for some of the newer tools browser stack seems pretty solid we've had a few issues with browser stack not the tool itself but just how do we get it all wired up how do we get it working but yeah testing was one of the ones where I think we a few false starts I think and it's what we I think we're now settling on what we're doing it's working really well but that that took a bit longer to get right yeah it's inherently tricky there the the you mentioned Patrol the folks that release that from lean code I know they would love to hear your feedback about any friction that you had talking to them at the moment matus is is on an email that I saw the other day amazing he was last no okay yeah he was on last year okay so uh of test automation is really high priority in our app because uh if our app fails the company cannot make money because the merchants cannot accept orders so whatever we release we need to make sure that we don't break anything uh that's why like widget test unit tests are the highest priority we have but at the same time we don't have really unlimited resources so we are trying to solve so many things and bringing like um the bar for the Automation and highest uh highest quality test quality thing it's not easy you need to invest and you need to have really good reasons to do that so we are of course investigating all all the time but there are other things at the same we are trying to fix so until that we are trying to do manual testing for this kind of native functionality such as camera uh notification receiving we know that Patrol brings us a solution but uh there Al there's also Maestro on the table because mro uh gives us opportunity to reuse what the native apps in other uh teams are doing and also U bringing external people to our project is easier when the Tool we use is used in other uh platforms as well so like although Patrol seems really promising and it's really smart uh we need to have some solution that is familiar to people who can jump in and contribute to this automation that's why Myro is now uh getting more attention from us yeah yeah I wonder if Patrol will ultimately take off most with flutter first kind of projects I think that could potentially be how that ends up playing out uh Dy yeah uh we have an automated test system a very large collection of test scripts uh they are written in Python uh so we developed a plugin uh to expose API so that the python script can control plut La so that way we integrated uh plut apps into the existing test system what was it like driving that from from python are you were you instrumenting the specific actions within the launched app and and what you're testing from python or you just oh you were yeah uh we can we can click a or send some uh key input and do the some text things like that like python appm binding similar yeah I see oh yeah okay uh SATA yeah so one thing I kind of crossed over is like end to end testing is a a tip of the pyramid we do focus a lot about uh unit tests uh and widget test that those are like we have 15,000 tests now that run on every uh merge commit so they they run uh they have to pass for you to be going through and also integration test uh on top of it and integration test because we are a web view in the front so uh we don't touch those things integation test can't touch those so uh and also we view them as component test meaning that we mock everything we have a custom rapper on makun proxy in Dart so we do all our integration tests boot of the simulator they run in our local CI uh but uh they don't actually hit the network hitting the network is the ma SP so uh we are uh we we very much focused on the testing pyramid and uh making sure our we can scale our app we're talking a lot here about kind of functional testing automating unit testing stuff think we've got some pretty cool Tools in to do that and we could probably talk all day on some of that stuff one of the areas that we focused on and made a commitment on was to make our app really accessible um we can often forget that you know there's a lot of our customers who who aren't as lucky as some of we are and their in their site and their hearing and their touch so there's quite a lot of customers that we need to look after and make sure they can use our app so we've invested a lot of time in that that UI framework and to I spoke a earlier making sure that that it works for voiceovers it works for screen readers it works for big screen small screen font scaling all the kind of stuff that can be easily forgotten about and you get picked up at the end we invested in a lot of that in our to earlier on um so when we're building screens we're testing the basics work so the things are read out and we do a lot of testing with some of our customers that are we kind of reading the things out in the right order so we do a lot of testing like that as well with our app and we're starting to get a really good framework where you know we get people who have got these kind of um vulnerabilities and we work with them to make sure that it's really really accessible that's um really really important for us yeah that's awesome I love uh it's it's easy sometimes for accessibility to be left as an afterthought and the flutter Community is blessed with a couple Champions who keep reminding everyone you've got to think about accessibility from day one so but the testing of it is tricky so that's great yeah I mean there's there's a whole thing with you know we got a point where I think some of our devs were probably getting a little bit too excited and carried away with some of the cool stuff we could do with with flut lot of cool stuff some of the packages are incredible out there right but you know we've if we have to focus on our customers and some of those need more help than others yeah I'd love to um let's talk more I'd love to dive into some of the specifics of your accessibility testing maybe share some some secrets with everybody because that sounds awesome all right next question again from Dominic just all faithful of good questions do you use any server driven Dynamic layouts if yes what are your strategies for example maybe a custom representation of a layout driven by a CMS like your own DSL or remote flutter widgets that's a package if you haven't heard of it but if you haven't heard of it you're obviously not using it or even plain HTML in a web view so yeah any server side uh server driven UI for many of you yes so sofa is a big product uh and we have lots of developers and one of the uh teams use D um they it is like a pure like a dump of flutter code and then there is a a parser within uh within our the client code and which interprets the the dump from server and then generates the widgets on the online I think there are lots of other Famers that do it but when we started doing it we didn't they weren there or they wasn't matured enough so we did our own thing um it works for the most part uh but it has its own challenges so it's not widely adopted but uh we one product definitely uses it I'm Happ to jump we we've got Max so I think like I mentioned earlier most of our stuff is kind of quite straight API driven go get content bring it back um the new app we built is every single string is content managed so from from day one it was all content managed and we built it all for multi multilingual multilingual for us could be you know we've not got the same problems D Young's probably got about rolling it out to a lot of countries we're based in the UK pretty much but been able to have a different kind of internalization or language set for younger younger customers H business banking customers personal customers we got it set up so that we could kind of toggle the content for that and the UI though we've we've integrated with content management so we have got some content driven screens um some of our app is completely driven from our content management platform we've not went full full in on that across the whole app because we thought it would get a little bit too complicated and a little bit too hard to manage um and then again being a bank as well we have got some kind of longer Journeys in there and you know you're applying for a product you're you're doing something that takes a bit longer some of that what the customer sees next is driven by the API rather than a cont content Management Solutions so bit of a mix We have got some web apps in there as well sorry so we've got probably all all versions of that server driven content in our app yeah one thing I kind of U missed is we do have the server driven and also there is another uh part of the project where uh we use BFF back end for front end uh which actually does the uh rest calls sorry graphql calls uh it's a graphql uh client and we have custom graphql uh binding uh within code we use ferry to some extent but it doesn't do all the way so we have our own Ferry uh wrapper and uh it's a complex back end so client will only send one like client can be sending multiple requests uh but all of them are kind of made into one uh Dart uh graph C call and we we'll be listening to that so uh it is still nent uh we are only using it in one product now uh but it can be it will be a big big thing uh in the next couple of years yeah I also can say that we prioritize BFF in our Solutions because it increases the modularity so when we have some solutions and we want them to be reused elsewhere we don't change the BFF implementation but the backand guys handled whatever is needed to make this work yeah all right another question this one very very internationally minded also from Dominic but there's a 200 character limit so it's been truncated to just D how do you handle legal requirements I also had to reword this to get it into 200 characters how do you handle legal requirements that can differ across jurisdictions at which point in your app does it know in what country it's operating and then decide which features to expose is that deduced at run time maybe compile time how do you keep yourselves compliant uh okay I can start I think this is one of my favorite things about being a front- end developer because we just request things and the backand people handle for example if you want to show some thing and if it is not legal then we receive null value so we don't show it so it's it's a bless to be a front end developer in this case because in the end most of the front apps front end apps are just showing the value and the back end people has the logic they just give us what to show and then we render it but what do you owe them to make that decision do you tell them the the geography of the user at that launch like how do they know uh I think the headers uh we add some information in headers like the local and country code so these kind of things are sent with every request okay yeah punt it onto the backend team perfectly valid answer just I can are a little bit differently we we're a UK company so we we and we're a bank right we've got enough regulations to worry about International ones so I think one of the things that we do we we we we basically just restricted by the app stores so the customers can download it in the countries that we allow them to that's align to us as a bank but also they can divide our brand we've got restrictions on what we can and can't do that um in the act when you think about regulation we um we need to make everything really simple for our customers to read so we have lots of te's and C's um we we focus quite heavily on making sure that that the ux and the customer sees is also really simple to read and understand so as we're not doing a lot of complex stuff around where you are what you're doing we do spend a lot of time making sure that people really get it so we're not expecting you to read every single line of a document we need to make sure it's really clear to customers what they're signing up for and help them that the stuff that we're doing is righ

2024-12-21 12:32

Other news