There’s a bit of confusion concerning the base64 decoding of the signed request returned by Facebook. Their FAQ mentions you have to use base64 decoding for URLs specifically which handle the proper character substitution for URLs.
The other error has to do with the end padding that is omitted. If you do a simple JSON parse on these base64 encoded string without padding, you may end up finding yourself missing a “}” on the end.
For instructions on getting the proper JSON, see this.
A good and simple overview of how initialization and configuration works, in detail, for Rails apps.
Add/Modify .ssh/config and add this entry:
Then you can simply log into your machine by typing:
instead of giving the complete path to your machine and identity file each time.
.. and integrated into the ActiveRecord gem no less!
In my days of coding, I’ve been lucky to avoid dealing with source control much. I spent some early days doing simple checkout/commits in CVS. Later on, I used SVN but typically on projects that I worked on by myself or with another, working in distinct areas.
Lately, I’ve started using Git but, again, in a single-developer situation.
Here’s a great article on how to use Git in a dev/prod environment with multiple developers.
General Rule of Thumbs:
- Keep in mind that the sandbox (development) environment is entirely separate to the production environment.
- Let me repeat: Keep in mind that the sandbox (development) environment is entirely separate to the production environment. Mixing device tokens and certifications across the environment will lead to a lot of nothing (that is, non responses).
- Servers needs push certificates from the provisioning portal.
- Clients register themselves with push services by communicating with Apple servers.
The two environments have items needed specific to them. More specifically:
- Servers need a separate developer certificate and production certificate.
- Client get a different device token when registering themselves in development builds vs applications downloaded from the App Store.
Therefore, the following rules exist (unless you do some hackery I’m not currently aware of):
- Development builds of your client (that is, any build put on your device from the development environment including Ad Hoc) will get development device tokens when registering with the APNS. Which means you can’t test production server settings with at development build on your client. Attempts to do so will lead to confusion and wasted time.
- Production builds (that is, the app actually downloaded from the App Store) will get production device tokens. These must be tested with production APNS server settings.
Last, but most definitely not least, you can only have 1 type of build on any given iPhone device*. So if you have a development build on your device and want to test your app downloaded from the app store, delete it first, then download your app and test it in the production environment (which it should be pointing to anyway). I didn’t delete my development build first and push notifications didn’t seem to work even though I attempted to install the app from the App Store (perhaps because it didn’t replace the existing app).
If you have an iPad you can install your iPhone app on there to do some push notification testing with your iPhone. iPads also accept push notifications themselves.
*You can have different builds if you utilize different app ids between development and production. I haven’t tried this out yet but it seems like yet another thing that might cause confusion when doing builds, especially if you forget about it.