All posts by Rob Fahrni

About Rob Fahrni

Rob is a husband, father, grandfather, and software developer. He started his career writing DOS based accounting software in BASIC, worked on Visio for 10-years, written a lot of C++/Win32 code, and now spends his time developing iOS Applications.

Happy Birthday RxCalc

Three years ago my brother and I introduced RxCalc. I remember arriving at his home for our annual Fourth of July festivities a bit bummed. I’d submitted RxCalc for review 21 days earlier and it still hadn’t been approved. When I walked in the door my brother asked if we’d been approved. I said no. We decided to go check the status anyway, and it had been approved! It was pretty exciting to see our first iOS application for sale and it was even better to know it shared its birthday with the birth of the United States of America.

Happy Independence Day!

App Store Reviews

Matthew Panzarino: “But the important thing is that there is a serious discussion now being had about this topic, which I feel is an extremely important one, both for Apple as the App Store continues to grow, and to the developers in its ecosystem. I don’t think anyone has the right answers yet, but I think that there are some very smart folks at Apple working hard on the problem, including the ex-Chompites. So I’m cautiously optimistic that we might see some results later this year.”

The entire app store review process has been a huge source of frustration for many iOS developers. I wrote about this problem in early 2011. RxCalc isn’t a huge seller, and we almost never get direct feedback from users. When we get a one star review on the App Store it’s often impossible to figure out what the user is really after. That’s where an Apple supplied method of contacting the user would be fantastic. We’d be more than willing to fill out a form at apple.com, have that reviewed by Apple employees, and have them forward that information to the end user. We’re not in the business of attacking our users, but we’d sure love to know how to improve our products. When we get a one star rating, we want to fix it.

It’s safe to say, we’re glad it’s getting some attention.

BUG = (LLVM Optimizer + ASIHTTPRequest + ARC)

I’ve been working on a project that makes use of ASIHTTPRequest for my REST needs. It’s been great, I’m a big fan of it.

When I started distributing my build to BETA users we noticed it would start and we’d have an empty screen. Huh? That’s not what was supposed to happen. It should’ve started and made a network request, instead it just stares back at you.

I spent quite a long time trying to figure out what was going on. At first I thought it was some weird TestFlight bug, but nothing could be further from the truth, TestFlight is a rock solid service. I finally posted a question to Stack Overflow, I was desperate. Then it hit me.

This has nothing to do with TestFlight and it only happens with the release build. No network activity, release build, using ASIHTTPRequest, and this is my first project built using LLVM. Ok, that gave me a much better Google search string. Off we went!

The Bug

Watch out! It's a blog fly!
It turns out to be a combination of things; LLVM Optimizer + ASIHTTPRequest + ARC, is the cause of my grief. Luckily I’m not the only person that’s discovered this problem and it’s documented on Stack Overflow as well as the ASIHTTPRequest Google group.

The Bottom Line

If you are using Apple’s LLVM compiler, ASIHTTPRequest, ARC, and building for release, or archive, make sure you follow the instructions outlined in the answer for the Stack Overflow post or the ASIHTTPReqeust Google group.

Calling all RxCalc Users

It’s been a while since we updated RxCalc and we’d like to know what you, our users, would like to see in a new release. We’re definitely interested in making RxCalc what you want.

Would you like different Pharmacokinetics Algorithms? We currently use Creighton, but we could implement others.

Would you like TPN support? Are there general usability changes you’d like to see? How about email support? Maybe templates for commonly used starts?

Let us know, we’re listening.

Detecting Conencted Devices in iOS

RibbitWe’ve been working with a client on a nifty little application that compliments their desktop workhorse. There are a couple cool things about this application. One it makes use of RESTful services to connect with their legacy system to collect and manipulate data, but that isn’t the coolest aspect of the project. The coolest part is how we collect user input.

Barcodes

Our client makes heavy use of barcodes in their application. To that end they decided to make use of KoamTac 300i and LineaPro Bluetooth barcode scanners. These two scanners include SDK’s so you can get tighter integration with the hardware. It makes total sense to get tighter integration because we don’t have any UITextView’s to collect input from a standard HID device. If you’re using a bluetooth barcode scanner and have a UITextView to collect input it’s fairly easy to use any scanner. It works just like a keyboard, but what about apps like this that don’t have a place to collect data? That’s where the SDK’s come in handy.

Detecting External Hardware

Since we have to integrate with multiple scanners we have to decide at runtime which scanner is being used. Using the SDK’s we could take a stab in the dark at initializing each one in turn and the one that succeeds to initialize is the winner. Not such a great way determine the one to use, but it would work.

What if there was a way to determine you had connected external devices without using a third party SDK? There is.

Using the External Accessory Framework you can do just that.

Here’s a little snippet of code you can use to get back a list of external devices connected to your iOS device. That’s all there is to it. The output produced from that small bit of code appears below.

Make sure you #import <ExternalAccessory/ExternalAccessory.h>

[code lang=”objc”]
– (void)_getAttachedDevices;
{
EAAccessoryManager* accessoryManager = [
EAAccessoryManager sharedAccessoryManager];
if (accessoryManager)
{
NSArray* connectedAccessories =
[accessoryManager connectedAccessories];
NSLog(@"ConnectedAccessories = %@", connectedAccessories);
}
}
[/code]

All this little piece of code does is get the shared Accessory Manager, EAAccessoryManager (man, I hate that name), and asks for connected accessories. Simple! The NSLog() call simply dumps out an instance of EAAccessory which describes the connected accessory. In this case we’re connected to a LINEA Pro scanner.

ConnectedAccessories = (
"<EAAccessory: 0x1f7810>
{\n connected:YES\n
connectionID:0xd0ff600\n
name: LINEA Pro\n
manufacturer: DATECS\n
modelNumber: XBAMBL\n
serialNumber: MSC140045UN11\n
firmwareRevision: 2.45.0\n
hardwareRevision: 1.0.0\n
protocols: (\n \"com.datecs.linea.pro.msr\",\n \"com.datecs.linea.pro.bar\"\n)\n
delegate: (null)\n}"
)

Need an iOS Developer to help turn your vision into reality? Get in touch, we’re here to help.

The Cost of Apps Development

I’ve been an iOS developer for the better part of four years now. Most of that time has been spent doing my own thing, but I’ve done work for others along the way. At one point a few years back I was bidding on some jobs for a games company. I sat down, looked at the document they’d given me, and wrote up a proposal.

A wonderful boquet of flowers.A couple days later I received an email back saying they thought my pricing was too high. Too high? Really? Basically they wanted to pay me about 1/3 what it would cost to develop the application. When you’re excited about doing work for someone and they come back at you with something like that, what do you do? You let the work walk out the door, that’s what you do.

It seems I’m not alone when it comes to people undervaluing the work of iOS developers. There is a really well know Mac and iOS developer, Craig Hockenberry, who chronicled on the true cost of creating the Twitter client, Twitterrific.

“With such a short schedule, we worked some pretty long hours. Let’s be conservative and say it’s 10 hours per day for 6 days a week. That 60 hours for 9 weeks gives us 540 hours. With two developers, that’s pretty close to 1,100 hours. Our rate for clients is $150 per hour giving $165,000 just for new code. Remember also that we were reusing a bunch existing code: I’m going to lowball the value of that code at $35,000 giving a total development cost of $200,000.” – Craig Hockenberry, 10.13.2010

I’m not sure if people think it should cost less because these applications run on a small device, or because the app store has turned into a $0.99 thrift store, but the truth is we’re professional developers. This is what we do for a living. You should expect high quality work with all the spit and polish you’ve come to expect in applications you make your living using. I’m not saying we deserve it, I’m saying we strive to earn it. If we don’t deliver what you expect, with the quality you expect, you won’t be back. That makes me work very hard to deliver something you’ll be very pleased with and proud of.

Recently another developer, Kent Nguyen, shared his thoughts on the subject and does a great job pointing out how complex applications can become. It adds up rather quickly.

“The process is not a simple one and I usually guide/educate the client through all the considerations using the following steps” – Kent Nguyen, 01.31.2012

This is a great source of information for anyone trying to decide if they need an iOS application. Know what you’re getting into, before you get into it.

Another Bad Review

We’re a bit bummed at the moment, we must admit. We haven’t checked the App Store for RxCalc reviews in quit a while, so we decided today would be the day. It was not encouraging.

In part the reviewer “found it less than useless.” Ouch. That statement really cuts to our heart. We want RxCalc to be your “go to” Pharmacokinetics calculator, we really do. We believe it to be accurate.

What do you do when you get a review like this? In our case, nothing. The reviewer didn’t contact us. We can’t fix what he, or she, sees as a problem because we don’t know what that problem is.

So, TXRph, if you see this, please contact us at support@applecorelabs.com, and tell us what’s wrong. If you can, please provide us with your calculations and what you expect them to be. We really want to get this stuff right. We have a PharmD on staff that verifies the calculations by exercising our algorithms, of which there are many different methods. Could it be your teaching lead you to expect a different set of numbers? Maybe, maybe not. If you see this, please, let us know how we can fix it.

There are thousands of users of RxCalc out there. We rarely get ratings from our users. It seems that we only hear from users that have a bad experience.

Take that how you will. We’d love to hear from you, good or bad.

Pretty please, with sugar on top.

We have a favor to ask. If you use RxCalc and have left a review in the App Store, please, get in touch with us. We’d love to have a conversation with you.

We have a bunch of great ideas for RxCalc but we’d like to put those on hold until we can resolve what folks see as under dosing. We’re pretty sure it has to do with the algorithm, or method of calculating kinetics, we chose to use, but until we hear from some of you we can’t be sure.

A wonderful boquet of flowers.So, please, drop us a line at one of our support e-mail addresses, or you can contact me directly at rob@applecorelabs.com.

Thank you.