Monthly Archives: November 2018

Xiaomi Pocophone F1 Review – MIUI And Stock Android

Uncategorized

I bought the Xiaomi Pocofone F1 earlier this month. My previous phone, the Galaxy S5, was already four years old, although still usable. But calls on the S5, as I mentioned in my Nokia 105 review, were buggy because of a faulty microphone/speaker/whatever issue. Apart from that one (which I could’ve just repaired), the phone was pretty okay.

Galaxy S5 and Xiaomi Pocophone F1 – about screen

I was running LineageOS 14 on my Galaxy S5 and very few apps so speed was not an issue in almost all cases. RAM management was pretty bad, but I wasn’t affected by it as much since I close my apps after use anyway. The camera had become quite crap after moving away from stock Samsung ROM, but that too wasn’t a big deal. The phone was 3G only, which was an issue. The bigger issue, however, was that it fixated on Edge most of the time. So I had stopped using mobile data (or relying on it) since at least a year.

And if you haven’t noticed, service providers don’t really care about 3G users anymore. Before Jio and the entire 4G revolution, the 3G speeds I used to get were easily more than 8-10 mbps. Now, 1-2 mpbs on a good day (which is probably because 3G is more of a fallback network these days than the flagship network it used to be). While not enough reasons to get a new phone, I still did as resisting didn’t make sense.

Front view – clean stock UI. Tempered glass on both for screen protection
Back view

The Poco F1 costed me around INR 19,800 in the Flipkart sale for the 6GB/128GB variant. I bought it after some extensive research (never trusted Xiaomi for some reason). But as it turned out, most of the Youtubers that I follow said good things about this phone. I checked XDA to make sure modding was easy and stock ROMS were available (learned this the hard way after I bought the S5). There were some issues like limited DRM support, sub-par stock camera app and screen bleed, but I could live with those.

Initial Impressions

I immediately noticed one thing. Moving from a feature phone (the Nokia ExpressMusic) to the Galaxy Note was a big jump. Everything was new with fancy options behind every menu. Moving from the Note to the S5 was like an update. Substantial but nothing fancy. I kind of knew what to expect: a slightly faster phone, a slightly better camera, slightly better battery life etc, which all turned out to be more or less true.

Moving from the S5 to Poco felt similar to that second upgrade, if not less than that. It was a step back in many aspects, like from Super AMOLED to IPS, IP67 to nothing and a comfortable one-hand-phone to a 6.2in phablet. But in most other cases, it was an improvement although not something that would make your jaw drop. Battery life is the biggest upgrade, from half a day to two full days. The camera is a decent upgrade (with all the fancy bokeh shots and slow-mo stuff). Theoretically, speed and memory management should’ve been a huge upgrade as well, but as I said, my S5 never felt slow thanks to the lean OS, so that was a minor improvement.

I can place cellular calls freely on this phone. No problem. Dual 4G support and hence I am able to use mobile data once again. The internal memory is more than what I’ll probably need (To be honest, my laptop has similar specs). Fingerprint scanner is very fast, and IR face unlock works in pitch dark. Cool stuff.

Software – MIUI

I must confess here that I had a prejudice against MIUI since the Redmi 1S days. It felt like the old TouchWiz, bloated and slow. That all changed when I used Poco. It was snappy (although still bloated), and the first thing that I did was uninstall all the sponsored apps that came with the phone. Soon, I started liking the skin. It was snappy, and full-screen gesture-based navigation was quick. The notch on the top meant I could no longer see the notifications without sliding down, but I got used to that real quick. Soon, the MIUI Android Pie Beta ROM was released and I updated to it manually. It was even better. GCam mod came to the Poco and many complaints about the camera quality vanished instantaneously. Night Node was included sometime later and it was magical.

The only problem I had with the MIUI skin, and this was kind of a deal breaker, were the ads. Everywhere. From file manager to browser, music player, themes. It is ugly, and feels dirty, to open a stock app and see ads. The unofficial Lineage OS for Poco was getting stable during this time, and I decided to give it a go.

Unlocking the Bootloader

While reading on XDA, I learned that Xiaomi allows for official bootloader unlocks, and doesn’t void the warranty of the phone even if you flash custom ROMs to it provided you can get it back to stock before taking it to the service center to claim warranty. I remember Samsung was similar at one point (although they didn’t make it official by saying it out loud, like Xiaomi). You know the instant respect++ you feel for someone after learning something nice about them? I felt that way about Xiaomi at that moment. Unlocking requires their official tool, 72 hours of waiting time and a few clicks. A few more steps to flask TWRP recovery and you’re put in charge of your ship.

LineageOS 16

I flashed the latest LineageOS and got back to stock Android. Honestly, it wasn’t a huge relief or improvement per se. I was kind of enjoying MIUI and it was fast enough. So getting to stock was just an assurance that I won’t see random ads popping up in the system apps, and that I’m running something that’s better for my privacy. I also installed AdAway for blocking ads in other apps and browser.

Overall Experience and Conclusion

Buying a new phone used to be like a mini festival when I was young. It isn’t so much these days. For me, the smartphone (and the modding associated with it) has reduced from a hobby to just another utility, like the refrigerator or scooter. I’m sure innovation still happens in the smartphone industry. It may just be that it isn’t relevant to what I do anymore. And while that sounds depressing, it has freed up a lot of my time that I can use to…umm…do important work **cough cough** memes **cough cough**.

I hope this phone stands the test of time, just like my Galaxy S5 did. If you’re thinking about getting this phone, I hope my review gave you some perspective (although you might want to follow the advice of the pros out there). That’s it for this one. Thank you for reading.

Let’s Talk About CSS

Uncategorized,

CSS can be deceptively complex. And to most programmers, rightly so. We programmers tend to find patterns that help us relate the new information to what already exists within us, draw parallels and think of real world analogies. That is one reason learning your second or third programming language is much faster than learning the first if they share some paradigms. But with CSS, many of us have a memorize-first approach. While it works, it is more fun (and easier to debug) if we understands a little bit of the under-the-hood stuff.

In this post, let’s try to demystify some of the aspects of CSS that we as engineers should’ve asked when we got started with CSS. Better late than never, right?

Understanding The Browser

Starting with something basic: When you request a webpage, and it is downloaded to your system (computer, mobile phone etc), it is in the form of HTML code (at the application layer, that is). The browser then parses the html, line by line, downloading any external resources that it finds with separate HTTP requests. The HTML that is parsed is structured as a DOM tree, which can be thought of like a family tree, but with HTML elements. DOM defines the structure of the page; what goes where and what information does each node have.

On the side, the browser (in that, the rendering engine) is also processing the CSS files. CSS files are processed, and then styles for each node (HTML element, that is) is calculated, and applied to that node. The end result is ‘painted’ and rendered to the client’s screen.

So as you can tell, it is pretty straightforward. What’s interesting is the process of calculating the styles to be applied to each node, and that’s what we’ll be talking about for the rest of this article.

CSS Parsing

There are a couple of challenges when deciding what style applies to a particular element.

  • The engine has to first parse the CSS and get all the values for each property.
  • Then the engine has to decide what set of properties get applied to each element depending upon the specificity of the selectors, inherited and default values (since each element may have multiple rules that seem to style it).
  • Then the selected styles are converted into pixel values (we may have used rems, ems, percentages or vh/vw in our CSS code) as that’s what browsers understand.

In particular, the CSS engine looks for the following when dealing with a style and deciding if it really applies to a given node.

!important

If a property has !important in the value, it is immediately selected for the final processing irrespective of the specificity and code order.

Specificity

To put it simply, specificity deals with how ‘specific’ is the selector (based on concrete rules). For example, if you have some list-items, each with a class selector and CSS background-color: red; and one of them also has an ID selector with the CSS background-color: green;, then which background-color do you think gets applied to that particular list-item? It is the style in the ID selector.

Similarly, if the ID selected list-item had an inline style, the inline style would take precedence. Formally the hierarchy is

Inline style > ID selector > Class selector > Element selector

Browsers maintain an internal tuple of the form (0,0,0,0) representing the counts of each selector hierarchy viz. (inline-style, ID, class, element). For the selector h1.heading#top-heading, the tuple will look like (0,1,1,1), that is, one for ID, one for class and the last for element selector.

Suppose you had another selector h1.heading#top-heading#blue-color. Now the tuple for this would look like (0,2,1,1) as there are two ID selectors. If the browser had to choose between the former and this, it would choose this one as it has a higher specificity.

Source Order

Now what happens if specificity of two selectors match? Simple, the last selector in the source code (even in case of multiple files) gets selected for application.

Cascade

Cascade (n): A process whereby something, typically information or knowledge, is successively passed on.

The term Cascading in Cascading Style Sheets says something about the priority scheme that’s used to determine what style gets applied to an element when multiple rules match. In simpler words, if body has font-family: Arial; specified and the h1 has font-family: Helvetica;, Helvetica gets applied to the h1. However, if font-family on h1 wasn’t explicitly declared, Arial would’ve been selected by inheritance. This is how inheritance works in CSS.

Not every property is inherited. And it doesn’t make a lot of sense to inherit everything either. For example, setting margin: 0 10px; on body doesn’t automatically apply it to every child of body which doesn’t have an explicitly declared margin property. The ones which don’t have an explicitly declared margin get a default margin of 0px. This is how default properties work in CSS.

The obvious followup question is, how to tell if something will be inherited or default value will be selected? Honestly, I’m not sure. I usually just ask myself if it makes sense to have this property inherited or defaulted. More often than not, that’s enough. In case you’d want to explicitly make a property to inherit or default a value, use inherit and initial keyword respectively.

In Closing

That’s it for this little primer. I hope you found it useful. For a nice illustrated guide on this, check out this article on Mozilla. Thank you for reading.