Hi all, thought I’d share an update on progress – it’s been a while.
Tapp – Time is being consumed here, and things are getting done. Tapp was the first app I built and the code reflects that unfortunately. As of a couple days ago I’ve begun what I’ll call Tapp2.
Tapp2 will derive strongly from Tapp, but will look very different than the original program. The goal is no longer to perform basic functions between Tesla vehicles and Apple computers. What Tapp2 will
try to accomplish the following:
- Provide an interface similar to that of the official Tesla mobile app
- Perform aerobatics with the information given from the Tesla API
- Use advanced functions to get things done (Harder = Better!)
- Save important data in its rightful location: Apple’s Keychain
- Use Tesla’s compiler to produce better graphics
- Construct better application navigation
- Clean up the rubbish from the old Tapp
- General quality and stability enhancements
That being said, there are some things I need to address about Tapp [>V1.5]
First item being the careless handling of access tokens, passwords and emails. Due to my lack of coding knowledge at the time, I used what I call ‘dummy textfields’ to get things done. This is actually not the worst solution possible, however, looking back it is actually awful. For example, the access token¹ that I keep mentioning: Tesla API sends the token, application receives it but cannot use it because it is in a function. I made text boxes with text that’s the same colour as the background, put them in the corner of the interface and used them like so
dummyTextField.stringValue = JSON["access_token"]
let token = dummyTextField.stringValue in other functions to use the token previously saved.
This could have been done in a lot of different and more relevant ways, as to save some memory and to prevent issues with the text fields.
Second item being the lack of security. For one, the application bypassed the Tesla SSL check (to prevent attacks) which was a huge mistake. Another thing is; if the user selected the “keep me logged in” checkbox, then the app would save the access token in the UserDefaults space. Not Keychain Access. This is a massive security risk because unlike Keychain passwords, UserDefaults values are just that; they’re user defaults that are meant to have values such as “SelectedMode” or “IsModelX”, not “1a2b3c4d…” and so on. Though this doesn’t harm anything as far as I know, this can be accessed by anyone at any time, providing physical or viral access to the computer. Typically, nobody will try to get into your user defaults plist file, because it is thought that developers would be smart enough to keep important user data under lock and key, and not plainly visible to all. My bad.
I’m spending some time here, and hopefully it’ll be whipped into shape soon! Here is a glance at the UI – it’s not near completion yet, I’ve warned you!
¹ access token – When the application submits a password and username to the API, the API responds with JSON, which contains the access token, token expiration time etc. The access token is then used with all of the other requests, it acts as a username and password combined. The token allows the application to, for instance, unlock the vehicle. One can see an example here.
That’s all for now, folks!
EDIT: ADBToolkit! It is being worked on, slowly but surely! Here’s a look at how things are going.