Finally fixed the #cocoapods problem I was wrestling with yesterday afternoon! My #littlelogs #Swift app wasn’t behaving the same as the original #objectivec one, and I couldn’t figure out why. I’m still not exactly sure, but I think maybe the cocoapod I was using wasn’t working because of how I’m subclassing in Swift. I don’t know enough about it to fully understand and fix that… but I did manage to recreate the same behaviour offered by the cocoapod all by myself! Turns out it wasn’t very complicated, I was just being lazy by using a library to do it for me 😏
Wrestled with my #swift version of #littlelogs for #ios this afternoon. I’ve realised I can use #objectivec #cocoapods libraries, so I’ve started adding in the ones I used in the #objectivec version of the app. For some reason, the one that lets me tap the background view to make the keyboard dismiss won’t work. I also tried another library that does the same thing, and even re-implemented it myself and still can’t get it to work. At that point I gave up and had a nap, because what a silly little thing to spend all afternoon on.
Yesterday/last night I did some more #swift coding. I’m still working on recreating my #ios #littlelogs app in swift, and it’s going okay! I still have a lot to learn (e.g. I get optionals in theory, but I haven’t got the hang of using them yet).
So yesterday I added a double-tap gesture to the Home screen, because I found in my #objectivec version of the app, it’s a bit slow to tap a log, wait for it’s detail view to load, then tap the heart to like it. So now I can double-tap to like a log!
I also started working on implementing the detail view for logs, so when you tap one, it opens a new screen with the log and its comments and a comment field. So far I have just the log content showing up.
Did a little more work on learning #Swift yesterday afternoon. It’s not getting any easier, or less frustrating. It annoys me that all my #Swift code has to be so safe, but according to @josh it’s actually no worse than #objectivec — only Obj-C lets me get away with doing naughty things more easily, like assuming the JSON response I receive will include all the variables I want.
Last night I played with #swift a bit more. I’m slowly porting my #littlelogs #ios app from #objectivec to #swift. It feels good to actually write some swift code, because the ideas really aren’t sticking in my brain just from reading about them. I’m really enjoying the syntax so far, but I’m a bit frustrated at the extra coercion needed to get swift to play nicely with #json, since I deal with #API results a lot. #laterlog
Made some better progress with #elm on #larder tonight. Got routing sorted out and am now officially manipulating the history when switching folders and viewing the add link form, which I also set up.
It’s been a challenge thinking about how to represent all the state and I worry about the best practices on how deep to go — should I represent the state of each input in my form (empty, filled in, validated, invalid)? Should the form itself have a state (in progress, submitted, invalid, complete)? I’ve no idea and I kind of wish it was already decided for me.
I’m definitely much more comfortable thinking about this from a server-side, OOP point of view, and I really miss being able to write and generate HTML from the server. I do love how snappy it is to click around my app without page refreshes, only reloading the bits that have changes, but on the other hand I would’ve been wayyyyyyy further ahead on this if I just did it all server-side in comfortable old #Django.
I guess it’s worth it? 😕
I've started reading up on #Swift syntax so I can read more about how the language works and actually follow the code examples. I don't like some of the syntax choices which seem ugly (like backslashes before passing in a variable and arrows to show the return type) but there are some interesting features that are really different to #objectivec, like tuples.