Skip to content

Posts from the ‘Development’ Category

Mobile Apps are Real Applications

July 3rd, 2014

Rob Fahrni

RibbitMartian Craft: “Do you want a one bedroom shack for $50,000 or a mega mansion for $2M+ similar to Facebook, Twitter, or Instagram? As with homes, many clients opt for a starter size for their first app. This allows them to build a solid foundation that will be setup to grow with them for years to come.”

This is another great article on the true cost of mobile app development. No, it’s not the first and probably won’t be the last. As a freelance app developer I have to share this kind of news with folks all the time. I’m sure other developers have these conversations, they go something like this…

Potential Client: “I’d like to build this application.”
Developer: “Ok, let’s talk about your application.”
Potential Client: “I would like this and this and this.” (Of course I’m paraphrasing, the client is obviously excited about their product, as they should be.)
Developer: “Great, what kind of budget do you have?”
Potential Client: “I don’t have a lot to spend, how much would you charge for everything I’ve outlined?”
Developer: “It will take X dollars to develop your app, just a ballpark figure. It could be more, it could be less.”
Potential Client: [Silence. Never heard from again.]

I don’t say this to embarrass anyone. I’m only sharing it because it is true. For every 10 people I speak with about developing an application I may only get one of them to talk to me past this point.

I’m not sure if there is some sort of psychological barrier because these are mobile applications and not taken seriously, or what? In the end this is serious software that takes time, and a lot of effort, to develop.

When you have an idea for a mobile application and need a developer, remember this: Mobile Applications are real software. Think of them as your web site, or that accounting software you use every day, or maybe a word processing package from your favorite software company. Maybe that will help with the sticker shock?

If you need an iOS Application for your business or need a developer to bring that app you’ve always wanted to life. Get in touch, I can help.

Regarding Swift

June 7th, 2014

Rob Fahrni

ZDNet: “In essence, Apple had one job — create a new baseline tooling for iOS and show a sympatico approach with how the rest of the industry actually operates — and they blew it.”

I don’t know anything about the author, but based on his statements I have to conclude he’s never written a line of production quality code in his life.

The last thing we need is a lowest common denominator language to allow iOS developers to make code that runs on other platforms. Ridiculous. We have the web for that. If you want a lowest common denominator experience, create a “responsive” website with JavaScript and be done with it. If you want the best experience, go native, with native tools.

Would C# be great on the platform? Yes, but there is no need for the .Net runtime because Cocoa gives us everything we need and it’s not garbage collected. No need for the additional overhead.

If you’re ok with the Xamarin approach, which is very nice, then you should, by all means use it. There may come a day when I’ll have to create an app that works for both iOS and Android and that may be the best approach, until then I’ll focus on learning the native platform tools so I can provide the best experience for my users.

Super Marius

May 22nd, 2014

Rob Fahrni

I have the pleasure of working with some great folks every day. These great folks just so happen to be great developers.

Here’s a classic quote from one of them. I just had to record it.

It may be elegant and encapsulated, but it also has to work.” – Marius Matioc, May 20, 2014

Old Code Never Dies

April 19th, 2014

Rob Fahrni

CheezyPing still worksI happened across some old C++ code I wrote back in 2001. I decided to put it up on GitHub for kicks, might as well put some history up for future generations, right?

I was curious to see if I could build it. The original project was built with Visual Studio 6.0, circa 1998. I have a copy of Visual Studio 2010, so I fired it up pointed it at the original cp.dsw file and was pleasantly surprised it converted. I selected Build All and got a few warnings about some ATL include files I no longer needed, so I removed those. The only other thing that needs correcting are a few warnings related to use of older CRT string copy functions that are not secure. If you’ve upgraded a C or C++ project over the last few years you’ll be familiar with this warning:

warning C4996: '_tcsncpy': This function or variable may be unsafe. Consider using _tcsncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

The code still builds and will execute, but if I were going to use it daily, I’d update it. For now, it’s OK, the code built. Maybe I’ll download a new copy of Visual Studio 2013, get it working with that, and check it in. It would be pretty nifty to create a Mac version by doing an implementation of the HttpIf interface using NSURL and NSURLConnection. This could be a GrilledCheese implementation. Hmmmmmm.

Anywho, once I got a build I hopped out to the command line, and ran it. I was surprised to see, it still works. Amazing.

Chris Dixon on the Mobile Web

April 9th, 2014

Rob Fahrni

Will write C/C++ for foodChris Dixon: “This is a worrisome trend for the web. Mobile is the future. What wins mobile, wins the Internet. Right now, apps are winning and the web is losing.

Emphasis is mine.

I don’t understand this school of thought. Most mobile apps use a web service. The web is not about a browser, it’s about the services on the web. A browser is just the lowest common denominator way to view a web service. Mobile apps are “winning” because the browser isn’t the best way to do the job on a mobile device.

I know it’s not a popular stance, but the browser has a long way to go. HTML, CSS, and JavaScript are fine, but limiting. It will continue to mature.

On mobile we have native access to the device. We can whatever the platform allows, which is actually quite a lot. Interactions are just a lot nicer than they are in a mobile browser. We can handle everything locally then push the results into your favorite web service so you can get to it from other devices, including, but not limited to your web browser.

The browser isn’t the web. It’s one way to view the web.

WordPress on HHVM

April 6th, 2014

Rob Fahrni

Duct Tape, fixer of all things!
HHVM Blog: “As of WordPress 3.9, and HHVM 2.0 the following changes aren’t necessary as WP have updated their codebase to play nice with HHVM, and HHVM has updated itself to support more PHP stuff.”

I know it’s not in style to learn PHP, but it suits the old man C developer in me. I found myself reading about HHVM and Hack which lead me to think WordPress on HHVM might be kind of cool. One little Google search and what do you know, someone else had the same thought, and made it work. Not only did they make it work, but it looks like the HHVM and WordPress folks worked together to make it happen. Even better.

Maybe one of these days I’ll have time to get an HHVM based WordPress installation up an running.

Web.Next

November 9th, 2013

Rob Fahrni

Dave Winer: “But all that has changed with the ability to access cloud storage from apps written in JavaScript that run in the browser. Software that used to require a central server, and was easy to attack, and had to scale for all sizes of use-cases, now can run in the browser, with little if any loss of power.”

Dave is excited he can host a JavaScript on a server and pull it to the browser to execute because it affords him the ability to do simple applications without the need of web services. I can understand his excitement. It’s less expensive than running a GIGANTOR set of servers to host your services and answer requests thrown at them from the client. Point taken. It’s a step in the right direction, but I still think services are necessary for all but the smallest of apps because browsers still don’t make great hosts for applications.

Bringing in the Harvest
I think designing services first is the more appropriate thing to do. Don’t think about the UI first. UI’s are a dime a dozen and should be lowest common denominator (browser), up to native, high performance, best of breed (platform specific; iOS, Android, etc.) Because mobile is so important today you can’t leave that out of any discussion about web based services. Most web apps I’ve run on my phone are pretty horrible performance wise, but I can run them. If I have a choice to get a native mobile client I always opt for it because of that.

Dave accused me of calling him stupid.

Far from it, Dave. I know you’re not stupid, I just have a different idea than you, that’s all. A differing of opinion, and that’s ok. I think you’ll be very happy with your new model and out of that we’ll see some great browser apps.

I’ve talked about it before. I’d like to see the browser evolve way beyond what it is today if this is the new “OS” for the web based world. It must if we expect to create beautiful, highly usable, fully functional applications like we did on the desktop before the invention of the browser.

When the browser can evolve to a faceless shell that is language agnostic and allows us to control it like a native application controls the desktop environment, man, then we’ll have something special, until that time it will provide the lowest common denominator gateway to the web.

Web Next

Can you imagine the explosion of high quality code and components that would flow out of a world where we’re not limited to the confines of the browser and JavaScript? It would be industry changing.

I’d love to see the browser community embrace the idea of a full CLI implementation and create a way to hit and endpoint URL that pulls a fully built application to the desktop that’s hosted by an “invisible” browser. [UPDATE: This part, about pulling a full app plays nicely with what Dave is talking about.] The browser should serve as the new OS giving the developer full access to a virtualized machine.

We’ll get there, some day.

Pelco SDK 3.3.1 – Collecting Devices C++ Sample

November 9th, 2013

Rob Fahrni

Disclosure

By day I’m the Development Lead for a small group of folks responsible for the Pelco SDK. This post is not an official Pelco article, just something I wanted to share.

Background

Last August I rejoined Pelco to help design a new object oriented version of the SDK and that’s what we’ve been doing for the last year plus. We’ve released four revisions of the SDK over that time period and are working on our fifth.

Something I’ve wanted to share for a very long time is how simple it is to work with our new Object Model to collect devices and play video. We’ve simplified the entire process. The original version of the SDK evolved from need, as a lot of things do, but over time it becomes more and more difficult to maintain and enhance that code without breaking backward compatibility. In the new Object Model we’ve worked very hard to make it easy and give you the power you need to code new solutions and give us a platform to build on in the future.

I plan on sharing a sample application after a very brief overview of our Object Model. The application, called EnumDevices, is a C++ application. You can find it on GitHub. I’d be happy to create the same application in C#/.Net. If you’re interested get in touch, rob@crabapples.net.

Overview

The Object Model is pretty simple, here are a few objects, just to get us started. You can view the entire list on PDN(it’s a PDF file.)

  1. SystemCollection
  2. System
  3. DeviceCollection
  4. Device
  5. Camera
  6. Display
  7. Stream

Of those we’ll discuss System, DeviceCollection, and Device in the sample. There is some boilerplate code you’ll need to write, but we’ll skip that for now, so we can get on with the sample. Look at main() in the EnumDevices sample, the boilerplate happens prior to calling the EnumDevices function. Something to note. This sample uses version 3.3.1 of the SDK, which introduced an explicit Startup() and Shutdown() function, keep that in mind if you’re using version 3.0 through 3.3, these functions don’t exist in those releases.

EnumDevices C++ Sample

On to the sample code. If you haven’t grabbed the code yet, head over to GitHub and pull it down, I’ll wait.

Some things to note about the sample code. It’s only available for Visual Studio 2010. Our SDK only supports Visual Studio 2008 and Visual Studio 2010 for the time being. I have no idea how it will behave in Visual Studio 2012 or Visual Studio 2013.

Ok, on with the code. We’re going to focus on one function in the sample; EnumDevices. This little bit of code will add, or get, a System, get the DeviceCollection and enumerate it. As it does it will print out the Device Friendly Name. That’s it.

Here’s the code, we’ll break it down below.

static void EnumDevices()
{
        // Create or get an existing system
        PelcoSDK::System system("admin:admin@pelcosystem://[insert your ip and port here]?alias=Enum Devices Sample System");

        // Get the Device Collection from the system
        PelcoSDK::DeviceCollection devices(system.GetDeviceCollection());

        // Iterate over the DeviceCollection and print out the device friendly name.
        devices.Reset();
        while (devices.MoveNext())
        {
                PelcoSDK::Device device(devices.Current());
                printf("Device Friendly Name: %s\n", device.GetFriendlyName().c_str());
        }
}

PelcoSDK::System

Dissecting the code. I’m sure the first line of code, where we create the System, will have folks asking questions. When we were trying to decide our model for creation and access of Systems we wanted to make it as easy as possible and provide a great deal of power without forcing the user to jump through a lot of hoops. In the end it was decided we’d fashion it after a URI Scheme. Today most people know what a web address looks like.

Here’s the line of code in question:

PelcoSDK::System system("admin:admin@pelcosystem://1.2.3.4:80?alias=Alias");

The interesting portion of that line is "admin:admin@pelcosystem://1.2.3.4:80?alias=Alias". In our scheme “pelcosystem” represents the scheme name, we’ve put the username and password information to the left of the scheme, before the @. Following the :// is the host name, followed by the port, and a query string. We use the query string for arguments, in this example we’re assigning an alias name to the System so we can use that to look it up later, or display it in our user interface.

Something else to note about the use of the scheme in the sample. It serves to do the initial add of the System to the SystemCollection and works to look the System up later, without going to the SystemCollection. Our sample could have also added the System to the SystemCollection by using the Add method directly on the SystemCollection, but it’s not required. That said, the first time you run this code it will be a bit slower than subsequent runs. The first time through the System and all its devices will be added to a local device cache so the next time you startup will be much quicker.

PelcoSDK::DeviceCollection

The second line of code is pretty straight forward. After we’ve created, or retrieved, a System we’d like to get the DeviceCollection so we can do something interesting. Maybe we’d like to populate a tree control with a list of devices, or just dump out device information to a simple console application, like this sample.

PelcoSDK::DeviceCollection devices(system.GetDeviceCollection());

There’s not a lot to talk about here. We’re constructing a C++ object of type PelcoSDK::DeviceCollection using the results of a call to system.GetDeviceCollection(). Now we have a DeviceCollection Object we can enumerate.

All of the collection classes in the SDK implement an interface called IEnumerator, it’s a template class that exposes three methods; Current, MoveNext, and Reset. These methods make it really easy to iterate all collections in the SDK with a simple while loop.

devices.Reset();
while (devices.MoveNext())
{
	PelcoSDK::Device device(devices.Current());
    printf("Device Friendly Name: %s\n", device.GetFriendlyName().c_str());
}

After getting our collection it should be in a “reset” state, but the first line of code above shows how to reset the internal iterator back to the beginning of the collection. Notice the while loop checks the result of the devices.MoveNext(). The MoveNext method will move the iterator to the next item in the collection and returns a boolean value, true if it has a next device, false if it doesn’t. Once there are no longer devices in the collection we’ll break out of the loop.

If we do have a device in the collection you can retrieve it by asking the DeviceCollection for its Current() object. Since IEnumerator is a C++ template the type of object returned is a PelcoSDK::Device. You can read more about the Device Object on the Pelco Developer Network(PDN).

EOL

Hopefully this sheds a bit of light on the direction of the Pelco SDK. We’re off to a nice start, but we have a long way to go, and we’d love to hear back from developers and partners. Please, reach out. Let us know how we’re doing, where we need to improve, and share your stories.

Until next time, happy coding.

iOS 7 Lowers the Bar

September 22nd, 2013

Rob Fahrni

iOS 7

A gift for you!If you’re an iPhone or iPad user Apple had a shiny new gift for you this week; iOS 7. I know, I know, it’s a bit of a jolt. I won’t lie. I hated it for a few days, but it’s beginning to grow on me. I’ve heard this time and again “Give it a few days.” I’ve given it a few days and it still seems a bit stark, but overall I’m happy with it. My trusty iPhone 4 seems much faster than it did with iOS 6. Bonus.

Benefit to Developers

I’ve written a few iOS apps over the last few years. Some have been lovingly designed by professional designers, others, like our own RxCalc were kept intentionally simple. Why? Truth be told Jay and I don’t possess the ability to make beautiful imagery for our app, so the design has to be simple. We developed our app using plain old UIKit, it works really well, is fast, and the binary is tiny.

With iOS 7 the bar has been lowered. A generic looking application looked fresh when iOS hit the streets. There were developers that created their own style and look, and, in turn, third party developers began to define the look of the OS, not Apple. Think about developers like Iconfactory, Tapbots, and Path. They all introduced applications that took the look and feel of applications way beyond standard UIKit, and that’s great. They stood on the shoulders of giants and moved the bar higher so the rest of the app ecosystem had something to reach for.

Third party developers created Pull to Refresh, the Hamburger and the Basement, and alternatives to UITabBar. All were very good innovations and gave us beautiful, very functional, applications. But there is a downside.

If you go against the Apple playbook, which isn’t a bad thing, you may end up creating something that doesn’t feel at home on a future release of an OS. Since iOS 7 shipped I’ve seen numerous folks comment about how outdated forward thinking and innovative applications like Tweetbot look.

I’m sure we’ll see an update for Tweetbot soon, but the point is, if your app has a completely custom UI it may take a lot of time and effort to make it look right in iOS 7.

Back to RxCalc and our choice to use UIKit, without custom design elements. Here’s how RxCalc looks on iOS 6 and prior, and it looks this what on iOS 7 before being recompiled:

RxCalc, UIKit for iOS 6 and older.

It’s not flashy, but it looks similar to Apple’s own Settings app, or Mail, on iOS 6.

Making an app new again

If you created a simple UIKit application your road to iOS 7 is simple. Most of the hard work has been done. You can recompile and your application looks new again.

Here’s what RxCalc looks likes when it’s recompiled with the iOS 7 SDK. No additional work, just a simple rebuild.

RxCalc, UIKit for iOS 6 and older.

Can it be spruced up a bet? Sure it can, but I can put this in the store today and it will look like it belongs.

That’s why I tweeted this a few days back:

It is super easy to get a fresh UI if you stuck to generic UIKit.

Reset

The bar has been reset, time for a new generation of user interface innovation.

Thanks, Apple.

Re: Senior Development Engineer

August 6th, 2013

Rob Fahrni

[redacted],

As much as I love the idea of this, I’m just not the right guy for the job. I just don’t have the energy to stand in front of a whiteboard an answer code questions for eight hours straight.

I love [redacted], I really do, and I wish you all the best in your search for a developer to fill this position.

Rob