I try to keep updating my personal apps and games every now and then and this time I made my website a bit nicer, more interactive and more modern š
I improved 4 things:
1. Nicer top menu
Previously, the top menu didn’t look like an important part of the page. The contrast between the colours wasn’t right.
After a change, you can clearly see a hierarchy of the website, that a top menu is something important and worth attention.
2. Refreshed About me section.
This section used to have a sad, dark background image (taken from some non-royalty free website so I had to put a copyrights info in a footer) and a text in a small box centered horizontally.
I got rid of that dark background, text takes more space horizontally now so you don’t need to scroll that much to see the rest of the website. I also added an interactive Twitter feed, you can quickly check what I post there š
3. Completely re-designed Personal apps section.
This section used to have a static, small image links to the App Store or to the landing pages of my apps.
I changed it to a fully interactive, modern, horizontal slider with the nice and big images presenting my apps and games. Also I’m not including there the apps owned by the companies that I worked for, it’s only my stuff, only apps that I fully own.
4. Google Analytics events
This is a purely technical change but worth mentioning as well in my opinion. So I have a Google Analytics tracking since I published my website in 2015 but I was not measuring clicks on the buttons. It’s been added now, including social media images and Personal apps slider so I can analyse what works for you, what doesn’t and try to improve it in the future.
I added my Quick10 game on ProductHunt this evening. You can find it here: https://www.producthunt.com/posts/quick10 . I’m looking forward to get some feedback from the ProductHunt community and make the game even more fun and enjoyable for all of you š Share the link with your friends please š
I prepared a small (or maybe not so small) New Year present for you! Thanks to my friend’s (she’s a product designer) work, Quick10 game has been completely re-designed. It looks much nicer now and I’m sure you are going to enjoy it even more. I also added 2 extra leaderboards (so there are 3 in total now), separate ones for Easy and Difficult levels. Happy New Year š
update 3rd January 2021 – I updated a landing page URL because the app has been renamed
After a few months of development I’ve published my new app called Forehand. It’s an app for table tennis players and enthusiasts. It gives you an access to:
– daily news from table tennis world,
– videos showing how to improve skills – you can submit your links as well!
– tips what bats to choose,
– tournament sheets to help you with organising the tournaments.
There is a social aspect of the app as well. You can comment and interact with other users’ videos, you can personalise your profile.
At the end of March this year, when the coronavirus lockdown began, I started missing table tennis. I decided to create a mobile app for table tennis players and enthusiasts. I already have a few personal apps and games in the iOSĀ App StoreĀ but I wantedĀ ForehandĀ to be a bigger, multiplatform (iOS and Android) and long term one. Something like a personal business card for a mobile apps developer.
As Iām an iOS developer, I started from an iOS app. Itās 2020, Iām starting a new iOS app, sounds like a great opportunity to learn more about SwiftUI I thought. So I started building the iOS version of Forehand using SwiftUI. It was going quite well letās say, I added a few initial screens.
SwiftUI project structure
First problems that I faced were around a performance of VStack. I had a VStack containing 5 WebView views, each of them loading a different HTML, embedded YouTube video.
WebView which I embedded 5 times (each with a different HTML) in VStack
Putting 5 instances of such a view was killing the performance, VStack was just almost non-scrollable.
Main issue number 2 was customising a navigation bar. Navigation bar on some of the screens was supposed to look like this:
Navigation bar with a custom background colour
or like this:
Another example of a navigation bar with a custom background colour
Unfortunately customising navigation barās background colour or its titleās background colour is not natively supported in SwiftUI and I needed to try some UIKit-ish solutions. None of them was perfect and at some point I even ended up replacing a navigation bar with a normal View. It worked, I could fully customise it but I didnāt feel itās a long term solution. At the end I left default colours.
The last thing that Iām gonna mention in this article about problems with SwiftUI is Onboarding screen. In UIKit we do it with UIPageViewController. Unfortunately there is no built in SwiftUI component for that yet. I researched Stackoverflow what workarounds other developers do, I found a few solutions. They were based on manually calculating frames of swiped views. It didnāt work well for all screen sizes unfortunately so I decided to use a UIKit bridge called UIViewControllerRepresentable. UIViewControllerRepresentable and UIViewRepresentable are protocols which let you embed old good UIViewController or UIView in a SwiftUI app. So I had Onboarding screen working but there was a navigation to the Home screen after tapping a Next button on the last page of onboarding missing. In a UIKit-only app it would be an easy push(viewController) or performSegue(with identifier) but SwiftUI screens are driven by state changes so itās a bit different.
I ended up doing something like this:
I was sending a āNextButtonTappedNotificationā from Onboarding SwiftUI view conforming to UIViewControllerRepresentable and it was being received by ContentView which is SwiftUI appās entry point. Not entirely clean solution but changing screens worked. There was a problem with a navigation bar though. I couldnāt get rid of an additional top header added by NavigationView / NavigationLink. I spent 2/3 evenings on that and taking into account previous problems as well I came to a conclusion that maybe it will be better to wait for SwiftUI 2.0 and not to spend my evenings on being frustrated and trying to fix things that are super easily achievable in UIKit. Thatās why I decided to stop using SwiftUI for the first version of Forehand. I rewrote everything what I had to UIKit views in 2 days and I started progressing with the project much faster.
Most of the mobile applications need some sort of backend, some remote data provider. Forehand is not different. As I am a one-man-band (in terms of devs, because I have an awesome designer working with me on Forehand too), I wanted to go for something easy to set up, integrate and multiplatform (iOS, Android). I considered 2 options: Firebase and AWS. From my previous experience I knew that Firebase is easier to set up, you donāt need to deal with a maze of permissions setup but on the other hand AWS seems to be more scalable. As I think about Forehand as the app that Iām gonna support and maintain for a longer time, I decided to use AWS driven backend for my app. Unfortunately I faced a blocking issue just at the beginning of the integration, at authentication stage. I want the users of my app to be able to authenticate using the following methods: Log in with Facebook, Sign in with Apple and Email + password sign in. Sign in with Apple is not only a nice to have sign in method, but itās also required by the App Store review guidelines if you have any social sign in method (including Log in with Facebook) in your app:Ā https://developer.apple.com/news/?id=09122019b. Even though AWS Cognito officially supports that sign in method as per this article:Ā https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-cognito-now-supports-sign-in-with-apple/, there is still an open issueĀ https://github.com/aws-amplify/aws-sdk-ios/issues/1809Ā and people try to find hacks to make it work. I didnāt want to go that way, I didnāt want to spend my evenings on finding hacks to fix AWS Cognito bugs and thatās why I decided to switch to Firebase where all sign in methods which I needed worked perfectly and the whole configuration process is really well documented.
Conclusions
Some of you may say that Iāve given up too early and thatās a fair point. I just want my free time that I spend on coding a personal app to be as enjoyable as possible. I also want to see the results as soon as possible, to touch what I build and to let other people touch it, test it, give some feedback.
Most of the SwiftUI issues that Iāve faced are fixed in SwiftUI 2.0 which will be publicly live this autumn. There are lazy stacks, native support for onboarding-like screens and much more:Ā https://developer.apple.com/videos/play/wwdc2020/10041/. I just didnāt want to wait a few months for SwiftUI 2.0 to be publicly live and then maybe 2/3 months to build my app from scratch using a technology that Iām not fully confident with yet.
In terms of a backend solution – Iām not forgetting about AWS. Maybe one day I will go for some kind of a hybrid solution: Firebase managed authentication and AWS for storing and providing data – I donāt know if itās possible though. I would need to do more research.
I hope this article will be at least a bit helpful for some of you. Please feel free to share your thoughts and experience with the technologies mentioned here.
update 3rd January 2021 – I updated a landing page URL because the app has been renamed
I have just started working on the new app called Forehand. It’s going to be an app for table tennis players willing to stay up to date with table tennis news and to develop their skills. There are 2 versions of Forehand app coming: iOS and Android one. I put a placeholder landing page at damianmarkowski.com/dmtabletennis already. I’m aiming to release the app on both platforms in June this year.
My new iOS app has been approved by Apple and is live in the App Store. It’s EasierSelfies. Thanks to this app you can take selfies much easier and quicker than with the default iOS camera. I noticed while travelling with a friend that it’s hard to take a selfie with an iPhone because of its camera button’s position and I decided to create an app with a movable take photo button.
One week ago I added Dark Mode support to 2 of my apps: Quick10 and DMProjects. It adjusts automatically to iOS device settings. In the next update I might add a manual switch to turn it on / off as well.
We do it (almost) every day, we review someone else’s code and our code is being reviewed by our colleagues. It might be a bit tricky for junior developers to get used to it at the beginning though. Let’s write down some useful tips about code reviews.
We do it to improve a codebase.
A main purpose of a code review is to get a feedback on your code from a colleague from the team. The is no developer who writes perfect code, we all sometimes miss something, forget to test some edge case or commit some unneeded code. This is why code review is helpful – you get someone else looking at the same code, someone who approaches code in a bit different way, who tests different cases, someone who didn’t spend on your branch 4 last days and looks at it with a fresh mind.
Try to teach, not blame.
Blaming someone because of not perfect (in your opinion) code doesn’t help anyone. It destroys that code author’s day, it destroys your day too. Try to phrase your comments in a way you would like to get feedback too, the way it can be useful, full of knowledge. I think it often sounds nicer when you use plural form rather than a singular one while requesting some changes: for example “Can we move it to a class level?” rather than “Can you move it to a class level?”. It shows that the author of the code is not left alone, that you are trying to improve this code with them.
Link documentation pages, blog posts.
Different developers have different opinions how particular code could be improved, changed. There are many cases when it’s just subjective, there are a few different opinions and none of them is the only “right” one. On the other hand, there are certain well known patterns, that experienced developers just use automatically. Less experienced developers might not know about them. While trying to suggest such options try to give a link to documentation page, blog post or similar. It may have one nice side effect – author of the code may save this link in their notes, keep it for the future and learn quicker.
I think I will conclude the post at this point. Feel free to add your own tips in comments. Happy code-reviewing š
