Projects

Yesterday I sat with Michal (@michal on micro.blog) and we had a quick talk about Gluon and my recent blog post explaining why I’d like to discontinue it for Android.

Whilst most things in this article are true, I had a change of heart!

So, instead of dumping it I’m going to be creating a special build just for Android. This probably won’t have feature parity of the iOS version, but will have most of the Gluon DNA.

I’ll be starting from scratch with a minimal build using what I know. I’ll take to heart performance and also use the minimal build tools I can use to get the best out of React Native and Android.

With a fresh start I can also start looking into build size and actual frameworks that are needed instead of just blindly installing defaults that I used. This will make me sleep easier at night.

I’d rather have a slimmer Android version than a bloated app or, worst, no app at all.

You may have noticed that the past few weeks have been super quiet on the Gluon front. This has been because of a few reasons, one of them being an influx of freelance work that I have to finish before the holiday… I have not been stressed and deprived of sleep like this for a while. It all seems to come in at once, when you least want it. However, there is another reason… which has taken me a few weeks to think about.

How Gluon is built

Gluon is built with [React Native](https://facebook.github.io/react-native/), which comes from you favourite company that everyone loves (not). React Native basically allows you to write everything in JavaScript using the “React” way, which in turn creates a fully native app. On top, I can probably share 90% of the code across iOS and Android. This, you see, is why I was able to move so quickly with everything. Not to mention the experience of a summer long job creating a big app for a German football club.

This is great and I’m happy I got something out the door that actually works well enough on iOS… and that renders something on Android without much work.

Dropping React Native and going all native

I wrote my first app for iOS just before Swift came out so I learned to write, and read, to some extend Objective-C… then transitioned to Swift as soon as it was announced a few months later. I vowed on that day that I will read the manual from front to back and know Swift like my life depended on it. After all, I always wanted to develop for iOS. It was great. What wasn’t great is that it kept, naturally and un-naturally, evolving at a super fast pace. Every year for a few years I had to update the app so it wouldn’t break or keep at the same big size over time, due to the embedded Swift libraries. The guide book also got bigger.

So 3 years after that I had a good knowledge of Swift but I had to relearn a lot of things. This was a bit too much to keep on doing every year, especially when your day job (at the time) programs in C# and you’re mainly stuck with that and on the side jobs trying to improve your skills in other areas.

However, I think Swift is great! Especially compared to something like JavaScript. Swift isn’t perfect, but it’s a 100,000% times better than JS. In JS everything can be anything and anything can be everything. A null can be a “null” on Android. A ZERO can be false, or actually “0” or a 0… depending how it felt on the day. Yeah sure, I can get around this easily, but you see my point hopefully (“OMG, he’s doing it wrong the n00b!”). Swift on the other hand is just plain type safe. I love that.

Anyway, digressing a bit.

Being stuck with mainly JS frontend frameworks (React.js) and React Native all this year… I think I’m totally over it for anything personal that I’m going to be working on. Things can get overly complex in a matter of weeks. However, I do enjoy using it at a small scale as you can do some really great things with. As they say… “Been there, done that, got the T-Shirt.”

So the main point is that I went down this road, can do it and was able to learn about this “hot” new JS framework of 2018. Not to mention living in the world of what is a 500MB node_modules folder per project… Who actually thought this was a great idea when they woke up one morning? When you freelance and work on several projects… that can become a problem.

Alright, so here is the nitty gritty.

I want to get back into the swing of full and native iOS development using vanilla Swift. This means coding in Xcode, building my interfaces like Apple intended and using their native API’s to do great things. I don’t want to rely on any third-party library. I don’t want to install anything via a POD. I want to know what my code does. I really want to embrace the eco-system that is iOS and also macOS. I don’t want to write another line of JavaScript for main parts of Gluon.

Not only that, I have looked closely at the performance of a React Native app, compared to a well written native app. If you want to drain your battery and spike your CPU, go the RN way for sure. Sure, there are changes coming to RN that will change this, but still… a great app should also be one that is mindful to the user resources. Performance on Android is just horrible for anything beyond basic. This is my personal experience. For sure, there are probably ways to do everything better.

Another contributing factor to my change of heart are these two nuggets from Daring Fireball: [This one](https://daringfireball.net/linked/2018/12/05/react-native-accessibility), and [this article](https://daringfireball.net/2018/12/electron_and_the_decline_of_native_apps)

Third party frameworks for creating apps like this are not first class citizens. They never will be. I had someone email me regarding Android and helping me look at the accessibility on Android. The first article above really speaks for the work that is involved to even get anything that is good enough.

Android

With the above, that also means that the life of the Android app will not see the light of day. The simple reason is… I’m not an Android developer and don’t want to be. Take a hard look at Android Studio and talk to me about developer happiness with a straight face.

Not to mention, we have a general “no Android” policy in this household.

Once Android becomes privacy first with better development tools, I may explore it in future. I don’t use Android day to day, so I have no clue what an Android app should behave like.

I think it’s wise to accept the fact that I don’t want to develop on Android. There are people that embrace iOS and people that embrace Android. In order to truly create something great, you should really stick to what you’re passionate about. Do not think “Meh, this works on both and is good enough”, without actually thinking about it. Or “let’s wrap this web app into an Electron app and be done with it”. No thank you.

So, for the tester on Android - I am truly sorry it has come to this. There are great Android apps out there and I would totally recommend you go with [Dialog](https://play.google.com/store/apps/details?id=com.dialogapp.dialog) for Android. I recently installed it to see how good it is. It’s great and was done by someone that understands, lives and breathes Android.

I don’t want to create a shitty “meh, good enough” app for Android.

At the end of the day, I’m concerned about the user and, of course, developer happiness.

The future

This is no easy task but I have set wheels in motion to start fresh, from zero. The current TestFlight for Gluon expires in 65 days. I may push another one out to keep that clock running a tiny bit longer whilst I work on getting it to the same state that the app is in now, with a few tweaks of course.

Android alpha will still be available until I ship the iOS version. You’re more than welcome to use it, so email me if you want to be on the list. It will, at some stage next year, go away.

I will blog about the process, as I go about re-building it.

For 2019, this will be my long running “code challenge” - re-write and ship.

It’s not going to be your usual attention grabbing app

Many social apps make you come back into the app by sending unnecessary push notification, badge your app icon with millions of red circles and white numbers… they badge your tab bar with icons to say “Oh hey, here is something new that YOU DID NOT READ… OMG STOP EVERYTHING”… or “Oh hey, you have a BILLION unread items waiting above”.

Gluon will not be like this. Gluon will sit there quietly until you open the app, ready for you. Ready for you in the now, the right here, in this moment of time. Not taking your time away from your family or other real social engagement. No FOMO feeling.

Too many times do I see people driving in their car, looking at their phone on some social network of choice, because they probably got a notification. Or teenagers chatting to their friends in front of them, looking at their phones because of some fake and created social thing they are in to at the moment.

Sure, that’s not my problem and sure… it may deter a few people away to another app. I don’t mind, because at the end of the day I know that I created a, hopefully, nice app that works great and has a few happy customers. That is all I want. If this reach is just me, then that’s good for me… if it’s 10 people, then I’ll be happy.

Life is busy. People are busy… busy in the wrong way, out of choice or habit. One reason I don’t use a task manager anymore… because I don’t want to be busy with managing it. Piece of paper for the day works for me for most things I do.

The official Mirco.blog app is great and love the way that notifications are just plain quiet. No sound, no attention grabbing tactics. At first, this was weird but I totally love this little detail.

My aim is this: Have a great working app across the Apple eco system, that is friendly and respects the user, doesn’t interrupt your time and which fully embraces the micro.blog eco-system.

And no, I will not make a [insert a really popular iOS twitter app here] clone.

Another day, another update to Gluon. I can't stop working on the app, it's a lot of fun for me and I'm learning heaps of great stuff!

Before I get started, I just want to extend a warm thank you to everyone that has left comments, emailed me and of course for everyone that decided to run the app on their phone. It really means a lot to me, so... Thank You!

Image Modal

In a previous build, released on Thursday, I added an image modal. I didn't say anything, but wanted to test it out in the field. So, now when you tap an image, you will be presented with a nice modal. If a post has multiple images, you'll be able to swipe left or right, zoom in, zoom out, you name it.

It was a bit tricky to get right, as I didn't want to reload any of the images when the modal opened. Another hurdle was to grab the image dimensions, before serving the image. Grabbing these, for some reason, was slow.

What I'm doing now is grab the dimensions and set the returned dimensions in local storage (cache), sorted by their URL. I also add to another local store, to record what URL I stored and when. More on why in a moment. As your timeline loads, and grabs images, it will both cache the image (as it downloads it) and also now sets the dimensions in cache. This is important. When you open the modal I didn't want to grab anything with another round trip over the internet to fetch any of the data again.

Of course, if data is missing, it will try and grab it all fresh.

All of this enables instant image loading when you tap on it, because in essence you already loaded the image in your feed.

Here is a screenshot of the modal, with a colourful image (image by @eli):

I'll be adding swipe to close to this also... didn't have the time just yet.

It was important for me to keep dimension cache to a minimum, as you might have a photo only timeline... after a few months that would be pretty big! To combat that problem I added a check, of the cache, to filter out everything that has been added more than 14 days ago. Granted, it's only a JSON list... but you know. 2 weeks is enough in my mind.

Have a play!

Settings - the beginning

If you have read my other blog posts, you could probably read between the lines that I'm going to add themes to the app. Today, I made the first step to customising the app to your needs. This is more an accessibility feature than a "theme" item, however it clears a path for many options that are applied to the app in real time.

I had to re-write parts of the app, especially the navigator, in order for this to work. I don't want to get too technical though, so I'll spare you. Happy to say that it works though!

With this task complete I was able to add the first user setting to the app: Content Font Size.

I'm happy with this as it proved that it can be done with ease and without a performance hit (on the production app - TestFlight and Android Alpha).

This was a quick addition to the Settings screen, so please excuse me as it still looks really bad. It will get better over time.

Here's how it looks:

Two, not so nice looking, buttons that enable you to increase or decrease to your choosing. The default size is 16 points. The minimum is 8 and there is no maximum. Of course, on top of this, you will also get any dynamic font sizing that you have set on iOS.

Here is another screenshot with bigger text:

The post preview is loaded randomly from the Discover feed. So, make sure you have at least looked at the discover section. I'm sure you did already... I'll make changes to this as I go, of course, and have a fallback to a more generic design if no posts have been found. It'll always grab the data from the post cache, so no round trips around the internet.

You can "Reload" a feed item that you see, just to try out other ones. Some may just contain images, so it'll be quite hard to see any changes.

Any changes you make to the content size will be reflected in real time. I know... something small... but for me that's cool!

Settings are saved locally, so they will always get applied if the app cold boots or does other things. The screens also receive all of the "Theme" data instantly, so changes will be quick.

Anyway, happy to have this working as now I can do more great stuff!

That's it for now.

As always there is a Trello board for up to date info on progress https://trello.com/b/GSIj8AVi and my dedicated section, on my site, about developing the app.

If you're interested in testing you can sign up via the TestFlight public link: https://testflight.apple.com/join/2sbnWuMK , or you can email me gluon@vincentritter.com. If you want to test the alpha build for Android, email me. And of course, you can reply via Micro.blog.