For this project I started out in Figma designing how I wanted the application to look and to prototype navigation in the app. I always find the prototyping stage a lot of fun and it can be very easy to get lost in the process, but the end result is invaluable and provides an amazing kick off point for a project.
For navigation I chose to use the go_router package. The stock Material Navigation leaves something to be desired and having full visibility of your app routes in one place with declaritive routing. Nested navigation support also allows for easier scalability and understanding of an applications structure at a glance, and plays well with Bloc.
For state management I chose to use the Flutter_Bloc package. I am used to using MobX for state management in Flutter and for this project I wanted to challenge myself to implement a different state management solution. Bloc presents improvements over MobX like forcing me to think about writing structurally because I don't necessarily have the benefit of MobX's flexibility. The end result is a completely clean UI layer, letting me pull all of my business logic away from my views and made desgining tests much easier!
I wanted to keep the storage simple in this application as I'm not targetting a production release. To do this I opted for Hive package. I chose to use this as it's a NoSQL storge solution which made storing my JSON models simpler and the implementation / documentation for Hive was great - assuming you don't attempt to access it through pub.dev.
As is always the case, testing when a database is involved was not fun. But luckily there's has a great package for this: hive_test. hive_test simplifies testing of my Hive methods by creating a new Hive instance in a temporary directory which is then torn down after testing is completed. This is ideal because it means we don't have to attempt to mock each method call to Hive and instead I can just use my regular hive methods against the new Hive instance.
- Clone the repository:
git clone https://github.com/davidlonsdale92/rugmi.git- Install dependencies:
flutter pub get
cd ios
pod installFirst of all you'll need to create and populate a .env file at the root of the project. You can use the .env.sample file as a guide for this. If you have an Imgur application registered already you can just populate the fields, if you not then you'll need to follow Imgur's API guide here.
Once you have this then just go ahead and choose which environment you want to run against and you're in! You can also launch from the terminal using:
# Development
$ flutter run --flavor development --target lib/main_development.dart
# Staging
$ flutter run --flavor staging --target lib/main_staging.dart
# Production
$ flutter run --flavor production --target lib/main_production.dartThere are many improvements to be made to this small application, not limited to:
I'm happy with the UI and style guide I created for the app but some animations would give it some flare and extra polish. I'd like to add a pull down to refresh function for the main page with a nice Lottie / Rive animation like you see in the Imgur app. I purposely chose to keep page transitions to a minimum but it might be worth exploring some more obscure and fun transitions to match the playful theme set by the brand images in the app.
Right now the application just uses local storage through Hive Box. It would be nice to hook this up to third party OAuth solutions for account creation like the Imgur application does (something like Firebase). This would mean creating a #/Out and Account/Profile flows but would unlock persistent storage of user data improving the experience dramatically.
Right now this is just a basic implementation of what could be possible with the Imgur API. It would be great to enable filtering / sorting for the gallery, upload new images directly from the app and replicate the comments section beneath images in the detailed screen.
I chose to focus on functional testing mostly around the state management functionality in the application. This is mainly because this business logic is used more frequently and is more likely to break when extending the application. However, testing of the API responses is also a good idea as there may be unknown changes to the API response that we don't expect and causes the application to crash. It would have been better to have created some models for responses I expect back from the API and use these to mock responses for testing purposes.
