The stock browser on the Samsung Galaxy S4 (launched with the “Internet” icon) has notoriously poor performance, particularly with JavaScript. In my particular case, I was trying to run an animation created in Adobe Edge. Chrome, on the same device, however, was flawless. Why the new Samsung browser is worse than the old one from the S-III is a topic for another conversation – one that I am never going to have now that I have found this solution.

Chrome is preinstalled on Samsung Galaxy S4 devices (that are sold in the UK, at least). What you’d love to be able to do is force the system to start Chrome. This is possible!

Key to this is that in the URL you should replace http with intent, the append the rest after the hash. Presumably (but I haven’t tested this), if the original URL scheme was https, you should modify the scheme=http part of it accordingly.

Stupid thing really. I’m using validation in Core Data for the first time. I have a managed object, it fails validation, which is good. I fix it, and save again. There should be no validation errors. But there are. Why?

The original, failed, managed object, is still in the managed object context. So even though my newly created second object passes validation, the other invalid one is still in there, trying to be saved, constantly failing.

I needed to [moc deleteObject:oldObject]; and then it worked.

It’s a simple mistake. Trying to search for terms like “too many validation errors second time” and “Core Data reset validation” didn’t work, because that’s not actually what I was trying to do.

It was after successfully trying out NSManagedObject reset that I realised what the problem was.

I installed Windows for Workgroups 3.11 over the weekend. Finally got networking up today. I’m writing this post from Netscape 3.0.

I tried to install IE5.01, but it can’t do much. I had to turn JavaScript off on both of the browsers, because they just can’t handle it.

Nothing works. Neither of these browsers let me log into Gmail, because they don’t support high enough encryption. Mobile versions of sites don’t work because the browser doesn’t support XHTML.

I might be able to find a more modern browser, but this is kind of proving that we shouldn’t limit ourselves when developing web sites to the lowest common denominator. Let’s stop supporting IE8 and lower!

There’s been a bit of news about Facebook’s new (or at least newly publicised) Contacts feature. The gist of it is that when installing the mobile app, you can have it sync your phone contacts with Facebook. That way, all your contacts are available on Facebook, and you also get Facebook friends’ phone numbers on your phone.

But what I haven’t seen mentioned, and what I noticed today, was that in my Contacts on Facebook, there were a whole lot of random people’s names and photos. With an Add Friend button.

Who are these people?

Most of them were French. I used to live in France. I moved there nearly five years ago. I was only there for a year, as a teaching assistant. A lot of my friends there were also doing the same. And we all had mobiles. And we don’t any more. That was over four years ago. And numbers get recycled.

So now I have names, photos and telephone numbers of strange people in France, because Facebook is making the assumption that if I have a phone number in my phone, and someone else has the same phone number in their Facebook profile, I might know them. It’s not the case, and it’s downright creepy. Some of these people don’t even have public profiles. Yet Facebook has sent me to their profile.

It’s not difficult to put a specific phone number (or a whole series of numbers) into my contacts, sync with Facebook, and then have the names, photos and any other public information Facebook has on whoever has that number. A nefarious individual would have a field day. They could call somebody, ask for them by name, know where they work and who their friends are. Children could also be put in danger.

This is either a major bug, or it just hasn’t been thought through properly. Just because I have a phone number doesn’t mean I know who they are. And it definitely doesn’t mean Facebook should tell me.

I’m writing to you on my shiny new Samsung Series 5 Chromebook, which I was sent by Google after the Google I/O conference in San Francisco earlier this year. It doesn’t have a normal keyboad. Which is somewhat annoying, as it’s missing several keys.

So, for your reference, here are the key combinations for some of the missing keys:

Other key combinations like Ctrl+W to close and Alt+Tab to switch windows also seem to work. I assume that the same key combinations that apply to the Linux version of Chrome would apply to Chromebooks.

As an aside, I’m not sure how these keystrokes are recognised in JavaScript. If I can be bothered I will investigate and report back. I’ll probably forget, though.

Also annoying is that it has a British keyboard, which I am not that used to any more, after working on iOS development a fair bit recently, and on my NZ-bought ThinkPad, as well. Wonder if I can switch layouts?

Strangely, it would only occur when compiling for the device. The simulator was fine. psc is an ivar of the superclass.

I did a bit of research and found the word @synthesize. I noticed that none of my other subclasses of that same class synthesized anything. I removed the synthesize statement. And it compiled. I put the synthesize statement back in, but this time with the backing ivar explicitly declared.

Time for a rant. If you are building an API, whether it is for public consumption or not, you should make sure you communicate dates in an unambiguous way.

You should always be able to figure out the exact time, regardless of time zone or daylight saving. The best way is to just use UTC. Or, if you can’t/won’t do that, you should include the time zone every time you mention a date. If you don’t, then you’re going to run into trouble when daylight saving ends, because you end up with the hour that precedes the changeover, and the hour that follows it, being the same. And that causes problems.

You should also not rely on date offsets from the current date, because your clients cannot be guaranteed to have an accurate time. So if you have an offset of 0 in your data that means “today” but your clients’ clocks are off, then they might think the data belongs as part of yesterday. Or tomorrow. And that is annoying.

Offsets from a particular point in time are fine though. And I don’t mind what epoch/reference date you choose. As long as it’s consistent.

APIs, in my opinion, are meant for computer-to-computer communication. They shouldn’t handle prettifying dates, for example. So you should pick the right tool for the job.