Sunday, May 04, 2014

Tips for Hub Integration on BlackBerry 10

A central feature on the BlackBerry 10 platform is the "BlackBerry Hub." This is the unified inbox of the device, where users expect to see all their messages and notifications. Starting in OS 10.2, there is now a (limited access) public API for integrating with this feature. Apps that integrate with the hub are able to provide their own icon, category, and actions within it. Apps that don't are limited to posting fairly simple notification items. If you develop an app that is messaging-oriented, users are likely to want you to become hub integrated.

Monday, October 24, 2011

Qt for the BlackBerry PlayBook

At the keynote to the BlackBerry Developer Conference last week, two very interesting things were announced.  First, the BlackBerry PlayBook Native SDK is finally in public release (it had previously been in a semi-closed beta).  Second, RIM unveiled the Native Open Source Components Initiative on GitHub.  This GitHub site includes ports of many open source libraries to the PlayBook, including the Qt Framework!  The only real downside here is that all they've done so far is to push out the code.  No how-to documentation has been provided.  Therefore, I'm going to attempt to give a walkthrough for setting yourself up to use their Qt port for PlayBook development.

Sunday, October 02, 2011

The mythical $800 hammer

I'm currently at the cusp of a major job transition.  For many years, my career has revolved around the world of Gov't contracts.  This began with a brief but meaningful stint as a federal employee, and has continued as a long journey through the world of Gov't contracting.  I've had a lot of personal reservations about this world, mainly in terms of the dynamics of the business models it supports.  With all the doom and gloom currently overshadowing the federal budget, and the industry downsizing and reorganization that is likely to follow, I think its time for me to move on.


For the last few years, I've spent a lot of my personal time on a major BlackBerry software project.  At many points, this personal project has provided far more interesting technical challenges and professional growth opportunities than what I was actually being paid to work on.  Soon I'll be flipping it all around, and doing mobile software development as my actual day job.  I'm curious to see how it will go, and especially how I'll sink or swim in the faster-paced world of non-gov't software development.

That all being said, I'd like to offer some slightly tongue-in-cheek commentary on why everything the Gov't buys is so expensive:

Where does the $800 Hammer come from?
  • First you need to have a DARPA program to fund research into advanced nail insertion technology (ANIT)
  • Then you have some Federally-Funded Research and Development Center (FFRDC) do an involved trade study that concludes that a simple hammer is preferable to the DARPA-developed ANIT prototype.
  • A program executive office (PEO) now hosts an industry day presentation on the US Army's Tactical Hammer Needs to the tool-making industries
  • The PEO now publishes a Request For Information (RFI) to solicit information from industry on steel hardening and handle-forming capabilities that could be used for the hammers
  • Finally a Request for Proposal (RFP) is published, along with a detailed performance spec, requirements list, and statement of work
    • There are a limited number of hammers desired, with options for buying more later
    • They also have to conform to various Military standards that no tool you'd buy at Home Depot would ever have to conform to
    • They need to be made in the US in a facility that holds the proper security clearances
  • The PEO finally selects one of the submitted proposals, awarding the contract
    • One of the loosing contractors decides to file a formal protest, and drags the process out longer
    • Eventually a settlement is made, and the selected prime contractor takes them on as a subcontractor for handle-to-head integration tasks
  • After several rounds of requirements engineering, systems engineering, and product R&D, along with approvals at preliminary and critical design reviews (PDR/CDR), the government gives the go-ahead to enter Low-Rate Initial Production (LRIP)
  • Testing eventually finds issues in the initial batch. Some design changes are made, costs are passed along, and eventually the hammer enters full-rate production (FRP)
  • Following training and deployment, the MK42 Tactical Nail Insertion Device (code-name "Hammer") is deployed into the field
  • Meanwhile, nails are getting tougher, and follow-on program for the MK49 Objective Nail Banger is announced

Friday, March 07, 2008

C# WTF: Abuse of events

Someone actually noticed my last post, so I'm going to start putting more of that stuff on here.

Getting a property through events:

Common uses:

  • Pretending to decouple classes for no apparent reason.



public delegate int GetSomeValueDelegate();

 

class Foo

{

    public event GetSomeValueDelegate GetSomeValue;

 

    public void DoStuff()

    {

        /* . . . */

        if (this.GetSomeValue != null && this.GetSomeValue > 4)

        {

            OtherStuff();

        }

        /* . . . */

    }

}

 

class Bar

{

    private Foo foo;

    private int someValue;

 

    public Bar()

    {

        foo = new Foo();

        foo.GetSomeValue += new GetSomeValueDelegate(this.HandleGetSomeValue);

    }

 

    public void Run()

    {

        foo.DoStuff();

    }

 

    private int HandleGetSomeValue()

    {

        return this.someValue;

    }

}



Common variants:

  • Having the event return a reference to the Bar instance that manages Foo.

  • Having the event return a property of singleton that is accessible from both classes.





Externalizing logic through events
Common uses:

  • Decoupling a class from its internal logic.



public delegate void ResultsEventHandler(string[] results);

 

class Foo

{

    public event ResultsEventHandler ResultsEvent;

 

    private string[] resultsData;

 

    public string[] Results

    {

        get { return this.resultsData; }

        set { this.resultsData = value; }

    }

 

    public void DoStuff()

    {

        string[] results = PerformOperation();

        if (ResultsEvent != null)

        {

            ResultsEvent(results);

        }

    }

}

 

class FooManager

{

    private Foo foo;

    private Bar bar;

 

    public FooManager()

    {

        foo = new Foo();

        bar = new Bar();

        foo.ResultsEvent += new ResultsEventHandler(this.OnResultsEvent);

    }

 

    public void DoStuff()

    {

        foo.DoStuff();

        ProcessResults(foo.Results);

    }

 

    private void OnResultsEvent(string[] results)

    {

        foo.Results = results;

        bar.Data = results;

    }

}

Thursday, January 03, 2008

C# WTF: Abuse of exception handlers

I've started collecting assorted examples of bad code, and will start periodically posting them. Everything seen here was first seen in real code (and fixed, when possible). Just remember, these are examples of what you shouldn't ever do! :-)

Type checking by InvalidCastException:

Common uses:
  • Checking the type of an object in a collection when the developer does not know about the "is" operator or its equivalents.


Selection selItems = UtilServices.GetInstance().GetSelectedItems();

if (selItems != null)

{

    try

    {

        foreach (object item in selItems)

        {

            // Cast to a Foo Item.

            FooItem fooItem = (FooItem)item;

        }

        ProcessSuccess();

    }

    catch (System.Exception ex)

    {

        // If an exception is thrown, the items are not FooItems

        Logger.Error("Exception: " + ex.Message);

        ProcessFailure();

    }

}



Null checking by Exception handler:

Common uses:
  • Not being bothered by the hassle of all those "if" statements.


try

{

    foo = bar.GetSomeData();

    thing = foo.ThingValue;

}

catch

{

    foo = bar.GetOtherData();

    thing = foo.ThingValue;

}

Thursday, April 12, 2007

Converting from a DIB to a System.Drawing.Bitmap

Yes, I even do some .NET programming in C# these days. Don't worry, its just at my day job. In any case, since everyone and their brother, cousin, and best friend seems to have a blog with random .NET tidbits, I figured I'd add one here too. (Speaking of which... Please, people, your blogs aren't so important that you need to fill 75% of it with links to other people's blog postings, lest your "special" readers never know about them. It makes Googling painful at times.)

In any case, I found myself inside some code that got an image (in native Windows "DIB" format, as an object that was of type "byte[]") and needed to convert it into a System.Drawing.Bitmap. The code actually did this already, by extracting the image size from the DIB header, creating a new Bitmap, then proceeding to iterate over every single pixel to directly set it in the Bitmap. Obviously that was way too slow, and a better solution was needed.

I then searched the web far and wide, not really finding anything useful. Sure, there were a lot of hints, but no real solutions. Bitmap itself actually has no easy way to be created from a byte array. What it does have, strangely enough, is the ability to be created from a pointer to unmanaged memory and some hints:

public Bitmap (
int width,
int height,
int stride,
PixelFormat format,
IntPtr scan0
)


Since I had my data in a byte[], not as a chunk referenced by an IntPtr, the first step was to remedy the situation. Here is how you do it, as weird as it may look:

GCHandle handle = GCHandle.Alloc(dib, GCHandleType.Pinned);
IntPtr handlePtr = handle.AddrOfPinnedObject();


(When you are done using the handle, don't forget to call "handle.Free()".)

Now all I had to do was offset the IntPtr by 40 (size of the DIB header), add in the information the existing code already extracted from the header, and create a new bitmap. Here's the final result:

using System.Drawing;
using System.Drawing.Imaging;
using System.Runtime.InteropServices;
...
GCHandle handle = GCHandle.Alloc(dib, GCHandleType.Pinned);
IntPtr handlePtr = handle.AddrOfPinnedObject();
IntPtr scan0 = new IntPtr(handlePtr.ToInt32() + 40);
Bitmap bitmap =
new Bitmap(width, height, width * 3, PixelFormat.Format24bppRgb, scan0);
handle.Free();
...


It may look ugly, and very icky, but it does work. In fact, this allowed me to take an operation that took two whole seconds of wall-clock time and make it instantaneous.

Monday, November 06, 2006

Frameworks, oh my!

Earlier this evening, I was having a little chat with my good friend and development wizard Chris. I was chatting with him about a recent frustration with the world of certain "Frameworks".

As I proceed forward in a software engineering class project involving an application built on JavaServer Faces running on top of GlassFish, I found myself reminded on this rant someone sent me a link to recently. While I ultimately have a far more balanced view, I do find his rambling somewhat amusing.

So anyways, here's my rant:

After a group meeting for my class, it looks like the most sensible way to design our web pages for this web app is essentially a templated composite view, so we can have standard headers, sidebars, etc, without having to code them on each page.

As such, I start looking up how to do them properly in the context of JSF (JavaServer Faces), which conventionally uses JSP (JavaServer Pages) for its page description system.

Then I start reading that you can do it this way, or that way, but that those ways all have problems for this reason or that reason.

In fact, most conventional documents on how to use JSF ignore the problem completely.

But when they discount all the obvious ways, they then recommend this alternate page composition system called "Facelets".

So I start reading up on Facelets, and it says how they use XHTML instead of JSP, because JSP is bad for this reason or that reason, especially with JSF, and talk all about how Facelets and JSF go wonderfully together.

As such, I look into what it'll take to have Facelets integrate cleanly with my chosen IDE (NetBeans), which I chose because it integrates so well with the other ways I was trying to do things.

I discover a NetBeans plugin that'll let me to Facelets, and provide all that tag-completion on the XHTML files that I was getting in the JSP files. Only problem is that its at version 0.3.

I install it anyways, and finally figure it all out.

In the end, Facelets has turned out to actually be a very nice solution, and I'm really happy with it.

(and since JSF supports plugable page composition systems, it integrates cleanly and correctly too)

But, given that JSF seemed to start from the basis of "we see all these other frameworks out there designed to fix/improve-upon what JSP provides", I wonder why I didn't start with reading about Facelets.

(and in general, I'm actually quite pleased with the whole JSF approach)

I just wish Facelets got more coverage in my JSF-bible-type book (published last month, co-authored by one of the spec leads). All it got was a few examples in the short chapter on plugable page rendering libraries.