Wednesday, 10 April 2019

Using Multi-Dimensional Arrays in Swift 5

Coming from old school programming, I sort of grew to regard multi dimensional arrays as a given; the stuff one learns at the second programming lesson during one’s early high school career. These days, that does not seem to be the case anymore, to the point of finding myself wasting way more time than I thought I’d need in order to figure how to work it out in Swift 5. This post is therefore here in order to help me solidify my findings, and if - in the process - I’d actually end up helping others, then I have done even better.

First, I will point you to the sources I have found the most helpful. That honour falls unto Paul Hudson for this post, to which I will add I have been finding his posts (and for that matter, his books) very helpful.
My second source of inspiration was this post Multidimensional Arrays in Swift from, which provides some good practical examples.
Feel free to pause and have a look at these two before reading the rest of this post.

On to the main event.
The problem I was facing, which can be generally summed up as “how do I use multi-dimensional arrays in Swift 5”, can be further broken down into the following:
  1. How do I declare a multi dimensional array in Swift 5?
  2. Once declared, how do I even address a particular member in the array’s matrix?
  3. How do I add values into such an array?
  4. In particular, how do all of the above happen when my array is not of a simple type (say, Int or String), but is rather a multi dimensional array of a complex struct that is made its own arrays, booleans, and other complex structures?
  5. How do I manipulate particular (and generally unknown) cells in the array’s matrix, while leaving most of the other cells alone? Specifically, how do I get to do that in Swift, with its prudish (but justifiable) emphasis on declaring and initialising anything and everything?

With that in mind, let’s have a detailed look at the various solutions and compromises I was able to identify. I’m sure experts will have a look and then laugh, but - regardless - this is what I was able to come up with within a reasonable timeframe.
The declaration part is easy. This is how one defines a two dimension array of a struct that I called Cell:
var grid = Cell()

Once declared, accessing a particular “cell” in the matrix is done via:
Where i and j point at the row and column in that array.

Obviously, before accessing grid[i][j] there have to be values there (or Xcode will raise a runtime error), which brings us to the more tricky bits.
I have found that simply asking Xcode to add individual “cells”, say grid[0][0], would not work. I had to append rows to the matrix first!
For example, in a case where I needed a matrix of 10 rows, I needed to do something like this in order to get rid of runtime errors later -
for _ in 0…9 {
            grid.append([Cell(value: 0, providedByUser: false)])
This adds 10 rows and 1 column into my grid, all of which contain data that I could - for now - ignore.
What is worth noting here, however, is the syntax I had to apply in order to append my values. As mentioned, individual cells in my matrix are made of a struct that is more complex than, say, Int; in this particular case, they are made of value (which is an Int) and of providedByUser (which is a boolean).

With this initialisation of the grid now performed, I was finally able to enter the individual values I wanted into specific cells of my grid. However, as per usual Swift standards, I had to do it properly and in order, so I ended up doing it using for loops:
for i in 0…9 {
            for j in 0…9 {
                if j == 0 {
                    grid[i][j] = (Cell(value: 1, providedByUser: true))
                } else {
                    grid[i].append(Cell(value: 1, providedByUser: true))
In the above, do note the different way of setting values when dealing with the first column of a row as opposed to when dealing with the rest of the row. That difference is a side effect of the fact I had already created that first column when I declared my 10 rows earlier with the minimum I could get away with - a single column.
Obviously, this very issue indicates at more elegant ways in which a multidimensional array could be set up. The point, if there was one, is to point out the importance of initialising rows in our multidimensional arrays and point a finger at ways to do so.

Now, if I want to print the values of my grid, that is how I do it:
for i in 0…9 {
            for j in 0…9 {
                print(“\(i) \(j) \(grid[i][j])”)

I cannot claim to be ecstatic about the way I manipulated the array in order to get the result I wanted, but I did end up with a working multidimensional (or rather, two dimensional) array. I guess if it was all lovely and simple, there would not have been a need for this post…
One question I still don’t have an answer for is, how do I achieve everything I had achieved here in a case where I do not know the size of my matrix in advance. I can think of ways around it, but they all require some form of non elegant manoeuvring that is likely to get frowned upon by the purists. Purists whose feedback and inputs I’d love to have, BTW.

Tuesday, 4 December 2018

Panda Arcade interview

It's been a while since I contributed to Digitally Downloaded, but I'm quite proud of this particular one: an interview with the Richmond (Melbourne) based indie developers Panda Arcade.
Panda Arcade are in the process of making a new mobile game, Pico Tanks. Essentially, it's a modern incarnation, online multiplayer, version of the good old Combat game that came bundled with my Atari 2600. Having played it at last year's PAX as well as this year's, I can report a family favourite in the making.
I'll quit while ahead and send you to read the interview here.

Monday, 6 August 2018

Follow the Apps

Most people take mobile apps for granted and never stop to consider the implications of using them. Well, there are implications, and privacy is one of them: when you use an app, you are - effectively - giving up on your ability to know what this app is doing on your behalf.
One very common thing for apps to do is to share your information with various players who make their money by collecting and harvesting our information. I’m talking Google, I’m talking Facebook, but I’m also talking about thousands of other companies most people have never heard of who make billions by selling our data. And, almost exclusively, they do so behind our backs (because we wouldn’t let them do it if we were aware of what was really going on).

There are ways for one to check on one’s apps.
One free and all conquering tool is Wireshark. You set it up on a computer in your network and it will tell you of everything going in and out; you can then examine it to see, in detail, what goes in and out of your phone when you use certain apps. The problem, however, is that for the laymen it can be pretty hard to identify the relevant from the irrelevant. Or, for that matter, it could be pretty hard to set Wireshark up in the first place.
Another way to check what’s going on in your internet connection is to use deep pocket inspection facilities available on some routers and switching equipment, particularly the more professional ones. For the purpose of the current discussion, I will assume this is either unavailable or is too technically demanding.
The easier and accessible for all way to see what apps are doing is to use a proxy app on your mobile device. When it’s running, all outgoing network traffic will go through that proxy app, and if it is designed for that purpose then it will allow you to peek into that outgoing traffic: where it is going, how much of it is going, and what is it that is going (as in, the actual contents). With regards to the contents, things are getting harder to assess given most apps use encryption (a much welcomed positive!), but the metadata at one's disposal is usually sufficient to make some educated assessments. For example, you can tell if an app of yours is uploading your photos to an online server.
My proxy app of choice for iOS is called Charles Proxy. I can attest that aside of having a lovely name and a lovely icon, it delivers when it comes to overseeing one’s apps.
Regardless of tool, the first thing you will see when examining traffic going in and out of an iOS device is just how often your phone calls home to Apple (and I assume the situation is very similar with Android phones calling Google home). It’s all encrypted, so you can’t tell what it is, exactly, but it does looks like Apple keeps track of opened and closed apps (probably for the purpose of assessing app popularity and such). The problem is, it’s all done behind closed doors so one cannot really tell what’s going on; regardless, we should all be aware of the fact our phones report a lot of stuff about us to the powers that be. It is something we all need to be aware of when we use our phones: you are not alone; someone is watching behind your back.
For now I will note that, given I ran my tests below on iOS, I have ignored mentioning whether apps call on an Apple service. It comes down to the fact that if you are using an Apple phone, you cannot hide from Apple. The same applies to Google and Android phones; Apple and Google’s surveillance is only limited by how far they are willing to go. In Apple’s case, it claims to be quite pro privacy (e.g., it offers navigation facilities using Apple Maps that don’t record where you are) yet it lacks in transparency. Google’s case is vastly different, with the company making its money out of its users’ data, causing it to often cross what’s acceptable (examples include tracking users’ location using cell tower data even when the user disables location services; there’s plenty more). I will put it this way, there are very good reasons why I happily pay Apple the inflated prices it charges for its devices.

Once you do start looking into apps’ behaviour, you’d be able to detect a pattern. Apps tend to come in one of the following flavours:
1. Apps that work just fine without calling any external party or any user tracking.
2. Apps that call home to Google.
3. Apps that call home to Facebook.
4. Apps that call home to a slew of other trackers, advertisers, and data harvesters.
I will note the above order of app escalation is not random. That is to say, apps that call Facebook seem to unanimously call Google, too. Similarly, apps that call on “other” trackers will not leave Google or Facebook behind.
It’s worth mentioning there are legitimate reasons for apps to call on the external resources of companies such as Google and Amazon. For example, Signal, one of the most secure and private messaging app out there, uses Amazon’s services. Similarly, there are apps that use Google’s storage facilities. However, part of the Google “contract”, if you will, says that they provide services in return for tracking. Similarly, Amazon Web Services is the engine that runs a lot of our internets, but Amazon is also a retail company running pretty sophisticated operations in the tracking and data harvesting department.

To demonstrate my point regarding apps and the tracking they come bundled with, I will point out real life examples for apps that behave differently to one another when it comes to respecting their users’ privacy. Obviously, there are a lot of apps to go through (in the millions!), but for now I will stick with three popular use cases of mine.

Camera apps:
Halide: Doesn’t call anyone.
Camera+ for iPad: Doesn’t call anyone (but do note there is a newer iteration of that app).

Photo editing apps:
Darkroom: Calls the dev’s home, a couple of analytics tools (Heap Analytics, HockeyApp), Apple’s iCloud (probably because that’s where my photos are stored).
Affinity: Calls the dev’s home and Amazon’s AWS.
Enlight: Calls Google, Facebook, and numerous others. Guess that's one app that quickly gets deleted off my phone.

Video playback apps:
VLC: As can be expected (?) from an app of such noble origins, VLC doesn’t call anyone.
Infuse: Doesn’t call anyone, but I will note I am using the old Pro version 4.
PlayerXtreme: Despite me paying for the premium app (there is also a free version), the app calls Google, Facebook, and numerous other trackers. It’s hard to tell what it is, exactly, that is shared; however, since I am not sure I would like to share what videos I watch with such entities, I’d rather stick with the likes of VLC.

PDF annotation apps: (I will add I grouped here several apps offering significantly different, yet overlapping, functionality)
GoodReader: As per its own statements, GoodReader does not share your information.
Notability: While this app offers superior annotation facilities (e.g., OCR, Apple Pencil support), it does calls home to Google.
GoodNotes: Very similar to Notability in form and function (though it had OCR years earlier), GoodNotes calls home to both Google and Facebook.
LiquidText: This otherwise incredible app for studying texts is also quite productive in the tracking department. It calls home to looking for something called (does the name tell us all we need to know here?). It also calls Facebook and various analytics/trackers like Apptentive, Crashlytics, and AppsFlyer.

I will add I find the above findings odd. In the case of Halide I actually communicated with the devs, who told me their apps don’t send anything, but then again my device clearly shows some [yet little] mobile data use by the app. It could have been a one off or a bug.
In the case of Camera+, I distinctly remember the iPhone version calling home with each use. Perhaps the iPad version is different, or maybe they changed their approach.
I guess my point is, if you see an app sending your information away then you know it does it; if you don’t, that does not preclude the app from sending information away at some later point in time. That said, I highly recommend Halide as my favourite camera app on the iPhone, and I think it is clear the developer has all the right intentions.

You might have noticed I did not include games in this survey. Which is rather odd, given games are known to be some of the worst offenders when it comes to tracking users. Especially the free ones, some of which are pretty blatant platforms for not much more than tracking their users.
My answer there is rather simple: Sure, there are plenty of ethical games out there that do not track their users. Regardless, given that the bulk of games do not need the internet to run (I will add: given the better games do not need the internet to run), the easiest way of dealing with their user tracking is to simply go offline when playing them.
Sometimes, the crude “old style” solution is the best solution.

Yet another solution for bypassing the tracking imposed on users by apps is to use a good old browser instead. That is, instead of using an app to perform an action (say, buying an item on eBay), go to the eBay website and perform the exact same action.
The reason for choosing the browser over the app is simple: on a browser, you can take control over who can track you or not by using ad blockers and numerous other tools that are widely available out there. On a desktop browser you can install add-ons such as uBlock Origin (ad blocker), Ghostery and Privacy Badger (tracker blockers that utilise different approaches to the blocking).
On iOS Safari, on the other hand, you can utilise ad blockers such as Firefox Focus, AdBlock, or one of the flavours available from Disconnect. The Firefox iOS browser itself comes with ad blocking built in, to various degrees, but it is not on by default. Then there is my favourite iOS browser, Brave, which comes with idiot proof tracker blocking built in and even offers script blocking for the more advanced user. Indeed, Brave has become my go to recommendation whenever the layman asks me for the easiest way to avoid tracking; it is, literally, idiot proof.
Sure, nothing here can completely solve the tracking problem, but this approach lets us, users, take some initiative.

If there is a way for me to summarise this post, it will be by stating that, the way things currently are, there is no way for a user to know whether or not certain apps come with user tracking or not without (a) paying for them first, and (b) testing them yourself while, at the same time, letting the harvesters harvest by virtue of your testing. Given the above examples, it is clear I would have never bought certain apps given the availability of others that do the same (more or less) but come without that extra burden of user tracking.
With the caveat of never knowing for sure before you actually bought the app, I will add there are certain indicators that can help. Some apps “smell” right while others don’t. Take VLC as an example: it’s open source, it’s a free download and has been for eternity, and therefore I wasn’t surprised to learn it doesn’t try to track me.
In contrast, all the apps that make a living through advertising are clearly prime time suspects, if only because of the fact those same advertising companies whose contents they show are also (usually) data trackers/harvesters. Clearly, this makes paid apps less likely to use trackers than free apps (with the notable exception of the ideologically driven apps, of the likes of VLC and Signal). It’s probably worth noting that trackers do not stop tracking even after you pay the extra fee to remove the adds, as is often an option.
Bottom line, probably the most effective way of assessing whether an app will exploit you for your data’s worth or not - other than paying and testing the app for yourself - is to try and figure out how, exactly, is the app developer planning to finance their operation. In most cases, us users can tell that in advance; sure, it takes time and effort to do this research, but on the other hand it is always worthwhile to ensure you’re installing quality stuff on your devices in the first place. For the same reasons you don’t pick garbage from the street to put in your house, don’t do it with any odd garbage you find at your nearest App or Play Store.
One last thing: If you do stumble upon an ethical developer that does the right thing, do support them! Give them some of your money, because they deserve it. And try to point to your friends and colleagues the virtues of those developers. The biggest problem a developer faces is obscurity, and if we can help the good guys with that then we are actively improving the world we live in.

Monday, 28 May 2018

Now broadcasting in HTTPS

You might have noticed this blog and my other blog are now using secure HTTPS connections (as opposed to the so previous decade HTTP). Then again, you might have not, given how rarely I’m posting anything these days.
Still, it’s good to know you are more securely accessing my blogs nowadays.

I would like to add a short clarification to explain what you gain and what you do not gain by using an encrypted HTTPS connection as opposed to the open communication of HTTP.
Essentially, when using a well implemented HTTPS connection (in this case, as it is organised by Google, we can safely assume it is), you’re making it way harder for third parties (that is, everybody other than you and the site[s] you’re connecting to) to know what it is that you’re doing at the site.
However, you do not gain anonymity through the use of an encrypted connection. That is to do with many factors. For example, your internet provider has the ability to know who your first port of call is by virtue of providing you with that access. The main point, however, is that most of the rest of the world can tell, too, if they really want, by virtue of the mechanism with which your computer finds the location of the website you are after. That mechanism is called DNS (which stands for Domain Name System, in case you cared), which acts like a the phone book of websites: you want to go somewhere, say, to Google in order to run a search? Your computer will head to the DNS directory assigned to it in order to find out where this Google thing that you are after is. And the problem, on the anonymity side of things, is that those DNS queries are (but for a tiny few exceptions) always done in the open and without encryption.
And the lesson is: an HTTPS connection is likely to improve your security, but that by itself may not have benefits for your privacy.

Friday, 8 December 2017

Simon Joslin interview

I recently interviewed Simon Joslin for Digitally Downloaded. You can read the interview here.
Simon is the main guy behind the Train Conductor series of games, games that left me with some dear personal memories (of the family type). I met with Simon at last year's PAX and we had a long chat; he definitely is a nice guy. As you can read in the interview, he's been doing interesting things and has plenty of interesting insight to share.

Friday, 25 August 2017

Peter Curry Interview

I recently got to interview Peter Curry, one of the makers of Mini Metro, for Digitally Downloaded. You can read the interview here.
I would like to use this opportunity to mention I consider Mini Metro one of the more brilliant game designs ever (and also one of my favourite game ever, but that is not the point). True, it is an exercise in minimalism; but there is more to it. I used to program simulations for complicated computer networks and factory floors myself; however, the thought of turning those into a game never occurred to me. I guess that is the difference between genius and average.

Friday, 30 June 2017

Jennifer Scheurle Interview

I recently got to interview Jennifer Scheurle for Digitally Downloaded. You can read the interview here.
Jennifer is a video game designer and educator. Originally from Germany, now living and working in Melbourne, she is very active on Twitter as @Gaohmee. I met her and chatted with her at PAX, and when Digitally Downloaded asked for developer interviews, she was my first choice.
To give credit where credit is due, the interview questions were written by Matt Sainsbury (Digitally Downloaded’s editor); I was merely the messenger boy. That said, most of the credit should to Jennifer for her wonderful answers.