HsoiContextualServices 3.0 is released.
It’s a long-overdue update to my old Finder contextual menu plugins, now updated for Mac OS X 10.6 “Snow Leopard” compatibility.
HsoiContextualServices 3.0 is released.
It’s a long-overdue update to my old Finder contextual menu plugins, now updated for Mac OS X 10.6 “Snow Leopard” compatibility.
In my developer career, for whatever reason I’ve escaped having to work on Installers.
Maybe I was part of a team and someone else was assigned to do the installer work. I might poke at a script here or there, but the bulk was someone else. Or I might be working on a project that didn’t need an installer, either we’d just distribute an archive, or we could do a simple disk image with a drag-install. Consequently, I’ve never really had to experience the pain of creating an installer from scratch.
I’m working on a small project that required the files to be installed in an obscure location within the User’s Library folder. Due to that, I figured it’d be best to use an installer. Besides, earlier this week I had to do a little installer tweaking on another project and felt rather clueless about how Iceberg worked so hey… might as well try making my own installer for the learning experience.
Holy crap, Lois.
I’m just amazed at how powerful yet how restricted package-based installers are. Good grief, Apple. Why is it so difficult in the second decade of the 21st century to write an installer that places something in the Home directory? Why do I have to resort to strange hacks, and having to resort to strange hacks is the established way to accomplish this? For a company that likes to promote how their products “just work”, this is FAIL.
I will say, Iceberg has some flaws, but seems to get the job done a little better than PackageMaker. I think Iceberg isn’t perfect either tho, like how it was non-obvious the Gestalt selector had to be entered in decimal not BCD hex, how if I checked the preflight script box before I selected a script, it wouldn’t select the script. It’s lacking some modernisms like automatic package signing, which PackageMaker has, and while that is something I can manually do, it’s nice to have it automatically part of the process.
I got the installer package created and it works, but geez. How archaic can you get?
Software developers: what do you use for placeholders?
The traditional programmer placeholder is foo followed by bar, baz, and qux. Certainly I use them, but there are times I need something more, especially if I need names.
That’s where The Flintstones come in. 🙂
I don’t know why I opted to use Fred, Wilma, Betty, Barney, Dino, Hoppy, Pebbles, and Bam-Bam…. even Mr. Slate, Joe Rockhead, and any other silly names like Uncle Tex, Ann Margrock, and Stoney Curtis. But in 15+ years of professional programming, The Flintstones are my go-to.
I write this because right now I’m trying to fix a bug in some address book functionality, which means I need names, and so Fred, Wilma, and Barney came along. I got to wondering what other developers use. Thought I’d post here and troll for answers (either here or via the Facebook cross-post).
Time to put on my programmer beanie for a moment.
One of the most useful features in Xcode is the ability to add “Run Script” build phases anywhere in a target’s build process. A little shell scripting and there isn’t a whole lot you can’t do to customize your build process.
One of my co-workers asked me if I knew of a way to perform privileged operations during that phase. I didn’t, but figured osascript might come into play. I finally had an opportunity yesterday to investigate this and sure enough, there’s a way.
osascript <<ENDSCRIPT
set shellScript to "rm -Rf /Users/hsoi/Desktop/TheTarget"
do shell script shellScript with administrator privileges
ENDSCRIPT
In an Xcode “Run Script” build phase, you have to use shell scripting (sh, bash, Python, etc.). I know of no simple way within a shell script to invoke Authorization/Authentication Services and pass that along. I do know you can do it with AppleScript, but via the do shell script command with the with administrator privileges option. So what do you end up doing? Creating a shell script (or simple command line instruction), embedding that into an AppleScript, which is executed via a /bin/sh script within the Run Script build phase.
I know. Convoluted. But it works, at least in the light cases that I needed.
Of course, you could go the pure AppleScript route:
osascript <<ENDSCRIPT
tell application "Finder"
set targetFile to "/Users/hsoi/Desktop/TheTarget" as POSIX file
move targetFile to the Trash
end tell
ENDSCRIPT
and if the Finder needs you to authenticate, it will prompt, just like it would if you directly manipulated “TheTarget” yourself in the Finder.
The bottom line is AppleScript will get the job done for you since it’s savvy to the OS and OS services like the Finder and Authentication. If your scripting needs are a little more complex you may have to do more work to get things working as you want them, but at least this provides a foundation.
Happy Scripting.
You know what’s better than UITextView?
At least, if all you need to do is display stuff. If you need editing, of course UITextView is what you want. But I’m working on something that only needs to display text. I started out using UITextView because well… I need to display text, it’s only logical to use the text view (duh!). And while there’s some cool stuff in there, like data-detecting URL’s and automagically turning them into tappable hyperlinks that open up in Safari, it’s just not the same. Oh sure, you can read in an RTF file to have all sorts of spiffy formatting and layout, but I’m pulling my text out of an SQLite database. Lacking good SQLite editing tools or whipping up my own editor tool, plus wanting a way to have rich media depictions, I realized: HTML! I can have text, I can format it however I want, I can easily edit it in the lame SQLite tools available, I can have images, I can have tappable links, I could even put in movies, references from elsewhere online…. so many possibilities!
Another cool thing about UIWebView is it can show more than HTML. Take a look at Technical Q&A QA1630. You can show Excel, Keynote, Numbers, Pages, PDF, PowerPoint, Word, RTF, and RTFD documents. That’s pretty damn cool. But, HTML suffices for me because gosh… you’re running atop WebKit. HTML5, CSS, JavaScript, all sorts of really cool things are available to you, and all you have to do is hook up a UIWebView and load the page.
So really, if you just need to display text to an iOS user but want something richer than plain old text, UIWebView is so simple to use.
However…
You should do a few things to ensure a good experience.
First, set your UIViewController (typically, but use whatever is appropriate) to be the UIWebView’s delegate (and heed UIWebView’s documentation about its delegate property). Then have the delegate object respond accordingly:
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
// If there's anything clickable, we don't want to show it inline; open up Safari to show it.
if (webView == self.myWebView)
{
if (navigationType == UIWebViewNavigationTypeLinkClicked)
{
[[UIApplication sharedApplication] openURL:request.URL];
return NO;
}
}
return YES;
}
(Apologies for the crappy code formatting… wordpress.com’s editor seems to be doing funny things to code and I can’t get it to play nice). What this does is “redirect” any clicks upon links. As it is, if a user tapped on a link, that link would open up right there in the UIWebView, which may not be the desired user experience. So, using the above code you can redirect any link taps to an external web browser (Safari), and maintain your UIWebView as a pretty panel of stuff. Nice.
I’m in process of converting my UITextView’s to UIWebView’s. It’s a hassle, but it’s generating better results. I can keep all of my data as simple text streams, I can format it and have a high degree of control over the formatting, I can include rich media. What’s not to like?
When I posted about “What To Teach The Kids“, I desired to write this side-bar on learning how to program.
You see, the trouble with getting started in programming is it’s difficult. Usually you want to learn to program because you want to do something, but there’s a lot of things you have to get straight before you can do something. It’s frustrating. You have to learn programming concepts, like loops, if-decisions, storage, subroutines and the like. You’ll have to learn higher concepts like factoring and organization. If you’re doing object-oriented programming you have to learn that whole paradigm and perhaps start to understand design patterns. Then you have to learn some language and all the quirks that come with it. You’ll have to learn some sort of library or framework. Depending what you want to do, there may be other specialty frameworks or concepts you have to pick up on, like for games work. I mean, it’s hard to get started because there’s so much you must have in order to just get started.
So how can you get started?
It so happens some other folks are presently discussing this, here and here. I think they’re headed in the right direction but haven’t quite gotten there. But the direction really is nothing new.
Back in undergrad I took this “abstract” computer programming class that used something called Karel the Robot. I remember in grade school learning to program in LOGO, which was kinda neat but looking back I see it was poorly taught and taught without direction… what’s the point of making this turtle draw a star on screen? But that started the ball rolling. BASIC was cool and very functional. But Karel was different.
Karel wasn’t out to teach you a programming language or other hard skills. Karel was out to teach you the basic theory of programming. Karel’s a robot that lives in a grid world. He can do a few simple things like advance, turn left, detect a beeper, pick up a beeper and put it in his beeper bag (I always thought “beeper bag” was a cute concept), detect walls. Very simple things, but from those simple building blocks you were able to learn concepts. For instance, you learned about the notion of subroutines when you wrote the “turn right” routine implemented as 3 turn left commands. And so it would grow from there. Karel was deliberately simplified so you didn’t have to worry about all the gory details that programming truly involves, so all you had to focus on was concepts of programming that apply anywhere regardless of programming paradigm.
Karel’s been around for 30 years, and truly I think this is the way to start programming because once you understand the concepts — and can do so free of all the other complex dreck — you’ll “get it” and be able to progress a lot faster. Karel’s been ported to numerous environments and languages, with an attempt to keep the essence of Karel but also give a gentle introduction to the language. I’m of mixed feeling about that because it removes a basic tenet of Karel: the simplicity of worrying about other stuff. But for those eager to get going, it may not be so bad.
Still, the trouble with the Karel is you can’t do anything useful, but that’s the tradeoff: ease of learning vs. usefulness. Again, when people get interested in programming it’s typically because they want to do something. So how can we get them to do something?
I’ve looked around for ways to teach kids to program, that honors the real tenants of programming — perhaps simplifying but not dumbing down nor misrepresenting — but still lets them do something useful.
I found this product called Stagecast. I’ve only evaluated it, but it looks pretty neat. It’s visual programming. It’s very simplified, a lot of click and drag and so on, but it still is true to real programming. The real bonus is the feedback and results are immediate. The kids can see what’s happening and how it all works. There’s no need to edit 500 lines of code across 20 files, wait for it to build, fix compiler errors, build again, then try to debug it. It’s like my “fishing vs. catching” analogy: there’s fishing, then there’s catching… you can fish all day, catch nothing, and it’s still a good day fishing. But if you’re trying to introduce a kid to fishing, they want to catch and catch soon else they will lose interest. So for kids, you have to start out with “catching” and as they start to enjoy “catching”, inevitably they’ll discover what “fishing” is. So I feel the same can happen here with Stagecast… let them “catch” and immediately create things in a simplified way. If they truly love programming then they’ll start to see the restrictions and limitations of Stagecast and want to explore further (“I want to write an iPhone game!”) and so, then you can start to introduce them along the path to other languages and other things.
If I picked a more generic path, I’d say the next step might be to teach them HTML. No it’s not a programming language, but it’s still simple, teaches formal constructs and organization, how to look things up in references, and again you get results but still have to debug those results. If they want to do more, JavaScript could be a simpler language to learn. I’d also say a modern scripting language like Python or Ruby would make a good “next step”. But exactly where to go from here really all depends upon their interest and direction.
Of course, something like LEGO Mindstorms would be wicked cool too, if you can afford it. 🙂
Getting started with programming is a daunting task because you have to lay so much foundation before you can do anything useful. I believe laying the core foundation of principles, through something like Karel the Robot, is a good approach to take. Then moving to simplified but immediately productive environments such as Stagecast makes for a good transition. After that, you just have to determine your goals and where you want to go. There are ways to get there in steps, you just have to be patient. 🙂
I’ve been working on a new programming project that’s new in every way. It’s a new project, it involves new API’s, new platforms, new paradigms, new things to explore… just about everything with this project is new.
When I get stuck and wonder how to get something done, first I turn to documentation. The docs are useful but generally are straight API docs. I need more conceptual docs, I need more HOWTO docs. So I look for sample code, and while some code is linked to from the docs, it many times hasn’t been enough to satisfy my question. So I do what has become natural in this day and age: turn to Google. Within a few keystrokes and clicks, I tend to find what I’ve been looking for. I can implement a solution in my code, get back to work and get on with things. Progress is quite rapid, all things considered.
What did we used to do?
I recall having to walk down the hallway to talk to other engineers at the company and ask for their help. Working from home for the day job and then having my own side gig, I just don’t have that luxury any more. Oh sure there are people I can turn to when I need it via IM or email or phone, but the world is growing so diverse in languages, technologies, platforms, APIs, and then the depth of what’s within those areas that often I ask someone a question and their response is “never used that before… never did that before… I don’t know”. 😦 While that isn’t solely a problem of today, in the old days we’d then turn to things like Usenet newsgroups or ad-hoc mailing lists; today we’d use web forums and official mailing lists But no matter whether we walked down the hallway or posted online, those all took one thing: time. If you walked down the hall you had to keep asking until you found someone who had a clue about the problem set, then you’d talk at great length, you’d get sidetracked, and eventually get back to your desk and work. If you posted online, you had to wait for a response with netiquette saying you should give it at least a day or two for people to respond. That sort of lag time isn’t always acceptable.
Now with so much content being online and Google’s amazing search capabilities, it takes almost no time. Chances are your problem isn’t unique, thus someone has asked about it before. And if you’re lucky, someone has responded with a useful solution… and Google was there to index it. Just craft your search string well and hopefully you’ll dig up what you need and be back on track within a few minutes of typing, clicking, and reading. The only thing we need is for people to keep their data online: websites can’t go away, blogs can’t close up, else that knowledge and information goes with it.
I’m quite impressed with how much I’ve gotten done this past week. With everything so new and having to wrap my head around so many things it’d normally take me a few weeks to get done what I’ve accomplished this week. The immediacy of the giant collaborative network that is The Internet is becoming a more awesome thing and powerful tool each day.
Been reading the official Android developer documentation. The Notepad Tutorial is the most complex introductory step-by-step tutorial they offer. Going through it I can say a few things that I find pretty cool, mostly about Eclipse.
All in all, it seems that Eclipse strives to help you out as much as possible. I like that. Sometimes I wish it wasn’t so helpful, but I reckon that’s probably because I’m not used to it. The real test will be spending a long time in this world then switching back to say Xcode and seeing what I miss and then hate about Xcode lacking. 🙂
I went to the bookstore and got the Pro Android 2 book. Of the various “How to program Android” books out there right now, this seems like it has potential to be the best one, not only in terms of how the book itself is put together, but the breadth and depth of topics covered.
The more I work in this, the cooler it is. Yeah, I also see more of the rough and painful edges, but yeah.. this is neat.
I did realize one thing tho. I don’t like looking at Android. There’s a grace and elegance that Apple brings to everything it does. They care about the design down to the last pixel. Looking at Android GUI? It feels like I’m thrown back to 8-bit Atari games. Not really, but that’s the only analogue I can think of to describe it. It just doesn’t look as graceful nor sexy as iOS or anything Apple does.
Now that I’ve gotten some introductory Android programming stuff done, the next step is diving deep into the developer documentation.
Still working my way through it all, but just reading through the Android Application Fundamentals and gosh… what a bunch of neat stuff. Or at least, so it seems here on paper.
How applications aren’t these monolithic things, but instead a collection of components. There is no main(). The notion of Activities, Services, Broadcast Receivers, and Content Providers. That’s pretty neat. Then how those Activities group together in a Task, how components across the system can work together, pushing and popping off the task stack. That level of modularity and integration is pretty cool. It’s like the whole system is a giant plug-in architecture of sorts.
I did my first “Hello World” style Android app yesterday, and while it’s only a first impression I wanted to share my first impressions.
My background is that I’ve been a professional Mac software developer for about 15 years and a hobbiest Mac and Apple developer since I was a wee lad. I used to work at Metrowerks, makers of CodeWarrior, back in the day when CodeWarrior was “the thing” for Mac software development. So I’ve not only used developer tools, I’ve made them. That all said, I don’t have a lot of iOS experience from a developer perspective because I’ve only so much time in a day and just didn’t have time nor a job that required it. But that’s changing and so into the abyss I go. I say this because yes, my initial Android experience is going to be tainted by the world I’m coming from. I’m not saying the new world is bad, just different.
Android uses the Java programming language. I haven’t touched Java in over a decade, and I know the language has evolved. First thing I did was pick up a book on the language. I bought Learn Java for Android Development by Jeff Friesen. The book has NOTHING to do with Android itself, it’s a pure language book. But I choose this book because the book is geared towards Android so it doesn’t waste time talking about matters irrelevant to Android, like AWT. I didn’t give the book a hard-read, nor did I bother with doing much of the exercises because I don’t feel I need it (famous last words?). I’ve used Java in the past, I’ve been programming for quite a while, and the book is geared towards someone who is starting from scratch. So talking about Generics? It’s akin to C++ templates so I just needed to get the details and differences. Container classes? Just give me an overview of what’s there, I don’t need to read 10 pages about all the various methods and what they do (that may come later for reference).
That all said, there’s a lot that’s changed in Java since I last really used it and I think a lot of the changes are good. Being able to “inline” a lot of things, nest classes, anonymous classes… it’s nice to just define your “callback” right there as you go along. It’s nice to have a language that’s more pure OO than C++ (Objective-C is pretty good at being true OO). It’s nice to see the library expanded, and things like Generics added. Yes there’s a lot of syntax I’ll have to get used to, but that’s how it is when you switch from one language you’ve used for years to one you haven’t. I should be alright.
But while the language is fine, the IDE is another story.
Oh…. I don’t like.
You see, every platform does things they way they do it because they believe they have something different and better. Mac OS X is one thing, Windows is another, Linux another… and everyone does their thing differently. Sure most of the core concepts are the same, but little details of interactions and how widgets work and the parts mesh vary. And Java apps seem to like to do things their own way, perhaps with a Windows-bias since many Java developers are Windows-based. Coming from the elegant world of the Mac user experience? Using Eclipse feels bizarre and klunky. I’m sure I’ll get used to it, but it still feels strange and like a step backwards in terms of human-computer interaction and experience.
One thing that really bugs me is I don’t like being forced into a tabbed single-window-only interface. I’m not that into tabbed interfaces, but I have come to appreciate when tabs are good and when they are not — for me. Apple’s really pushed a single-window mode of being on Mac OS X, and for the most part that’s alright. What I find I like is the ability to exist how I want to exist. Sometimes I want two windows because I need to arrange the content as I need to to do my work. Other times I want these “windows” to be grouped together and thus having the content in multiple tabs within the same window makes the most sense. I like options. If Eclipse allows me to escape this tabbed world, I haven’t found it yet.
You want to develop for the Mac? These days it’s pretty much Xcode. You download, you install, and off you go. All the apps you need, compilers, libraries, documentation, everything. It’s simple and rather painless.
To develop for Android? I had Eclipse installed from a prior thing I was working on, but now I had to get another version. So download that. Then I have to download the Android SDK and put that somewhere and tell Eclipse about it. Then I have to actually download and install all the API’s and tools for developing Android apps. Then more configuring. Finally, I can get going. What a pain. I don’t really blame anyone for this because the nature of the beast is so open, requires things from different vendors, and there’s a lot of flexible options. I do think options are good, but I also think there’s something to be said for providing a setup to get new folks started. It’s a high bar of entry, and I can only wonder how a total programming newbie would handle this. If Google could provide a “one click download and install” that gets you going, that’d be awesome. Sure it may provide more than is needed, it may bias towards one product or SDK or something, but get the n00b going, then once they grok the world they can sort things out and streamline later.
Nevertheless, things are going.
A friend sent me this blog posting on writing your first Android app. I figured I’d give it a try before I went through all the Getting Started stuff at the Android Developer website. First, this blog posting was great because it gave better instructions on how to get the tools downloaded, installed, and configured. Thank you for that!
But as I worked through this, it helped me see how spoiled I am in the MacOSX/iOS world, especially with how integrated the developer toolchain is.
Designing the user interface. So, I have to hand-write XML? Holy crap… I thought we were in the 21st century! Oh sure there’s a little tool to work it, but it sounds like no one uses it and it’s very rudimentary. That everyone just prefers to edit the XML by hand. Man, that’s…. unacceptable in this day and age.
Then to hook your GUI into your code, you have to do all this manual labor in code to make it happen. Yes, I’m spoiled by the actions and outlets paradigms in Cocoa, where in my code I can just declare an IBAction or IBOutlet, then in Interface Builder just click and drag to hook everything up. It’s a small thing, but it’s there.
I do like Android Virtual Devices thing, where you can simulate any sort of device. That’s of course necessary, but it seemed to run a little smoother than the iPhone/iPad simulator.
As an aside, I got to learn about a cool prototyping/wireframing tool called balsamiq. That app is way cool.
The first impression I’m left with? Android as a technology might be really advanced, but the developer experience is archaic. The toolset just feels really klunky, and I can see how spoiled I am with Apple’s tools.
That said, that’s the toolset and I will work with it. I’m sure I’ll get used to it and come to find things I love and things I hate. I’m still looking forward to delving deeper into the world of Android development. I’ve only begun and I’m sure my impressions will change, but first impressions are important and the impression I’ve been left with is one that desires more. Here’s hoping for the best.