Intro
Many people at Web3 Summit in Berlin asked me how it was possible to create an entire custom mobile app during just one midnight. This article is the in-depth technical answer.
History of PlutoFramework development
In November, I started to refactor the PlutoWallet code to make it even more modular and customisable. After the refactor, the development of UI components was not just tied to the Wallet itself. Developers received much more control over the whole app.
In January, I started developing realXmarket mobile app as the first production ready app developed with PlutoFramework. I started developing it as a fork of PlutoFramework (in this repository). This approach had a certain benefit and also obvious limitations.
- Benefit: each improvement to the app could also be easily merged into PlutoFramework. This way, PlutoFramework would start improving at a rapid phase.
- Limitation: multiple forks had to be maintained at the same time and a lot of merge conflicts had to be resolved, which was slowing the development down a little bit.
It was a good trade off at the time but this approach certainly was not scalable.
That is why I have decided 4 weeks ago to start refactoring the PlutoFramework code completely to fix these limitations and make the development of PlutoFramework more scalable and creation of new mobile applications even easier.
PlutoFramework refactor
Here is a quick overview of what changed:
1. The PlutoFramework csproj (C# project) was split into App specific code and PlutoFramework (shared) code.
This way, you can add app specific parts that would be typically irrelevant to other developers. The PlutoFramework code that is shared with other developers does not have to be touched at all. You are just free to use it however you want. In case you need to change/improve the PlutoFramework code itself, you can and you are welcome to make pull requests.
2. PlutoFramework.csproj was turned into package.
3. PlutoFramework.Model.csproj merged into PlutoFramework.csproj
There is not a need to separate these two projects now. It was confusing other devs anyways and this is a good simplification that we could make now that the PlutoFramework.csproj is a package and not an app. We wanted to have unit tests for model functions and apps can not be used for unit testing, because they build and run differently.
4. Added the concept of Templates
A new dedicated templates folder contains pages, .net maui controls and UI components that are meant to be reusable while their entire code can be modified and applied in the places where this templated item is used. Great example is a PageTemplate, .net maui control that is used as a regular ContentPage. By default, the PageTemplate contains a custom background image + ScrollView and a few popups that are always useful to have. PageTemplate should be applied to all Pages and the design of the page can be modified and customised by the final application.
- The content of the page is reusable but the page design itself is custom.
This concept gives a lot of flexibility to custom modifications while keeping the PlutoFramework code maintainable.
5. Resources
Better use of .net maui resources. You can customise colors, spacing, corner radius, background color, shadows and so much more.
6. Customisable layouts have been ditched
The Customisable Layouts concept (also known as PlutoLayouts) from PlutoWallet has been removed. It is not needed, it is a PlutoWallet specific thing. Other apps that know exactly which layouts are going to be used can just hardcode them and enjoy the performance improvement. After feedback, working with PlutoLayouts has not been the easiest and hardcoding is definitely going to be the easier option for developers.
7. Default endpoint selection is now modifiable through resources
8. PlutoFrameworkAppTemplate
A new app template has been created to scaffold new apps. It can be found in this repository: GitHub - RostislavLitovkin/PlutoFrameworkAppTemplate: App template for PlutoFramework
About the development of proof of concept apps
On Monday, I was thinking about what to show during the presentation at Web3 Summit. I got an idea to just make a new app with the PlutoFrameworkAppTemplate. I was always a big fan of Koda.art, so why not create a mobile version of it? And 1 day later, after I attended a Polkadot meetup organised by Parity, I got inspired to create another mobile app, this time a clone of the official Polkadot app.
Koda mobile app (proof of concept)
The resulting app code can be found here: GitHub - RostislavLitovkin/KodaMobileApp: Proof of concept, unofficial mobile app of koda.art..
I knew exactly what I wanted from the app:
1. Connect to Polkadot Asset Hub and Kusama Asset Hub
I had to select these endpoints so that they would be connected to.
The connection logic is handled by PlutoFramework. It would take a lot of effort to get the connection to multiple blockchains right. Instead, anyone can rely on PlutoFramework’s smart management of node connections and optimal data loading.
All datatypes and functions are generated through Substrate.Net.Toolchain.
2. Load balances and allow transfers
There are already UI components ready to be used in PlutoFramework. They did not have to be coded from scratch. I just had to add the BalanceView + Transfer and Receive buttons to the MainPage and that was it.
3. Find Nfts owned by the user
The Nft loading logic is implemented as part of UniqueryPlus, which is part of PlutoFramework. PlutoFramework also contains all of the important UI components related to Nfts. Once again, just reusing the logic that is already part of PlutoFramework was the smartest option.
4. User Onboarding
Wallet creation/seed-phrase importing is also part of PlutoFramework.
5. Custom design
I took the inspiration from koda.art design and I had to modify the resources to match it.
6. Other changes
App icon, splash screen, app name, etc. had to be also changed.
Polkadot app clone (proof of concept)
The resulting app code can be found here: GitHub - RostislavLitovkin/PolkadotAppPlutoFrameworkClone: Polkadot app proof of concept app made with PlutoFramework.
These were the steps of development:
1. Connect to Polkadot, Polkadot Asset Hub and Hydration
I selected these endpoints.
Hydration is used as a price oracle.
2. Create a custom UI component for displaying balance
I had to design 3 new UI components to display the balance with the same design as the Polkadot app
The balance loading logic was taken from the already implemented model functions in PlutoFramework.
The balances loaded have been filtered to only display DOT, USDT and USDC and to ignore other memecoins…
3. Create custom transfer and receive buttons
These buttons have been also created as a new UI component to match the design.
4. Colors and UI style
Has been modified in resources
5. User Onboarding
Wallet creation/seed-phrase importing is also part of PlutoFramework.
6. Other changes
I was very lazy to change the App icon, splash screen, app name…
Final thoughts
Yes, it might seem like cheating, however I think it is a clever design to already reuse the logic that was created previously. The important point I want to make here is that it does not matter how easy or difficult the development was, what is important is the final result and PlutoFramework helps you get there.
If anyone has more questions, firstly take a look at the git commit history for each of the PoC apps.