First devlog of the new year! Hello 2018!

Even though #Devember is over, I plan to continue writing devlogs as I found that even on a broken schedule, it helped to keep my mind organized and forced me to make notes that were more coherent than what I keep in my Zim Wiki. With that said, onward to trying to get to 100 Days of (non-consecutive) coding.

Devlog for day 12 of my #100DaysOfCode coding challenge.

Checklist

Daily Requirements

• 1 hour of coding #100DaysOfCode
• Devlog

Extra Tasks

• self study following my own syllabus
• startup or personal project work
• job related tasks
• get involved with Open Source

Progress Report

So the big task I tackled today was getting my current demo code to run on real devices smoothly so I could test my app in real life. It would also help make sure that the setup and integration code I used was solid before I started adding more packages.

• Android was already working before adding redux, redux-persist, and react-navigation. The only thing I had to do was make sure that I remembered to put my API keys (Mapbox, Google, react-native-background-geolocation) into the config files and code before installing on device.
  • Especially Mapbox as forgetting to configure the access key would cause the app to crash on startup without any sort of warning or error message.
  • Meanwhile, react-native-maps could be a bit tricky as it might show you a blank Google map with just the logo even if you have a valid API key. Why? For your Google API keys, either make sure no bundle identifiers are listed or that you add the current project’s bundle identifier to the list. This might have thrown you off if you were reusing an API key for an older project where you had added a bundle identifier.

• iOS, on the other hand, was far more difficult to get running on a real device. Following the official instructions and setting up things like your Development Team was easy. However, having integrated a new native code modules, things were bound to get messy.

  • The first issue I ran into was a compilation complaint about not finding the React folder that looked something like this: clang: error: no such file or directory: '...Build/Products/Debug-iphonesimulator/libReact.a'. To fix this, I had to comment out/remove this code from my podfile that was in the react-native-maps instructions:

    123	#if target.name == "React" # target.remove_from_project #end

  • Then I updated and installed the new podfile with pod update and pod install. I don’t know if this is the proper fix, but I got the idea from reading through this issue thread and this StackOverflow post with the same error. it got rid of the error and didn’t cause any issues down the line when I did get things working.

  • The next error I got was one complaining about XCTest that gave the hint to disable ENABLE_BITCODE. At first, Googling made me thing that this was somehow related to having to disable xip, but that did nothing. The proper fix was to open your iOS workspace (the one generated by CocoaPods) and disable the Enable Bitcode feature in the build settings. Once you do that, Xcode will be able to build and install the project to your device.

Now this isn’t all ideal. Having to open Xcode whenever you want to test on a device instead of a simulator can be annoying since everything else is done by the command line. So I delved into learned about how react-native run-ios’s various options worked. This is what I learned:

• The documentation around this on the website is sorely lacking.
• The --help is better but actually misleading as there are bugs that prevent you from doing simple things like picking a simulator with a specific iOS version to test on. Sidenote: I’ve got a bug fix almost done for this issue (as it was prematurely closed) and for this abandoned PR. I just need to learn about Jest and how to write proper tests per the React Native guidelines.
• Having dove into the code for run-ios, there are actually some untested functions and a bit of rewrite that would make things more clear on intended functionality. There is also a bug with --udid that I referenced above. It’s actually a bit scary how low the test coverage is for such an essential part of React Native’s tooling.
• Lastly, if you want to run on a device via command line, you need to install ios-deploy via npm install -g ios-deploy. Given that everything worked through Xcode, this will make things magically work for the command line.

Working through all of this took a bit under 2 hours, but it was definitely worth it. I’ve refreshed what I’ve learned about bumbing through Xcode and Android build files, learned a lot about the run-ios feature, and might even be on my way to writing my first open source patch!

Copyright © 2011-2020 Ho Yin Cheng