That is no problem.  You simply have the AIR app implement an interface
(e.g. com.company.project.IPrintServer), and copy that interface project
into both apps.  Then you can ask (in the air app)

if( parent is IPrintServer ) {
    //rock and roll!
} else {
    //hide print btn
}

You might also be able to simply ask if the parent exists, and then just
assume that no-one else would ever load your app, but the interface is
probably a cleaner way of going about it.  Not sure what kind of sandbox
issues you will run into, but it should be doable.


On Mon, Sep 6, 2010 at 5:07 PM, Laurence MacNeill <[email protected]>wrote:

> Ooh -- that sounds interesting!  I'll give that a look, and see if that
> might work for us.
>
> What would be perfect would be this:  Can I get my Flex app to tell whether
> or not it's been loaded by the AIR app, or whether it's in the Flash
> Player?  There will be times when we don't need the print functionality of
> the AIR wrapper -- it'd be nice if we didn't have to use it 100% of the
> time, only when we were going to need the printing-controls.  If I could get
> the Flex app to recognize when it had been loaded by the AIR wrapper, I
> could pass the print jobs to the AIR parent when that parent is available,
> and send them through the usual Flash Player print process when it wasn't
> available...  Is there a way to do that?
>
> L.
>
>
>
> On Mon, Sep 6, 2010 at 4:53 PM, Scott Talsma <[email protected]>wrote:
>
>> Another approach would be to create an AIR wrapper that encapsulates your
>> print functionality.  The AIR wrapper then loads the Flex app
>> (mx:Application).  You simply put together what you want to have printed
>> (FlexPrintJob) and then pass the instance up the parent chain.  That way you
>> can continue to maintain your Flex app as you are currently while slowly
>> getting your feet wet in the AIR world w/o committing the entire application
>> to AIR.  (Additionally, you can continue to host the Flex portion online for
>> update purposes; you just point the AIR "print client" at its URL.)
>>
>> On Mon, Sep 6, 2010 at 4:10 AM, Darin Kohles <[email protected]> wrote:
>>
>>> As (now) a desktop app. vs a web served swf:
>>>
>>> If you want to do it by hand, you'll have to change the main file from
>>> <mx:Application> to <mx:WindowedApplication>; do a diff on the "." files in
>>> the project folder (compare to a generic Air app), 'cause there are a few
>>> changes.
>>>
>>> If you want to add network sensitivity there is a bit more coding,
>>> otherwise have your "not connected"/"fault" errors handled appropriately.
>>>
>>>
>>> That's about it! ... of course there is digital signing, update
>>> awareness, @etc;.
>>>
>>>
>>> On Sat, Sep 4, 2010 at 2:39 PM, Laurence MacNeill <
>>> [email protected]> wrote:
>>>
>>>> To clarify, I'm aware that FB4 has a "convert from Flash to AIR"
>>>> wizard...  I don't trust wizards to actually do the right thing, in most
>>>> cases...  In fact, I generally find that they break more than they fix...
>>>> So, I guess I'm asking for your experiences with this wizard, if you have
>>>> any...
>>>>
>>>> Thanks,
>>>> L.
>>>>
>>>>
>>>>
>>>> On Sat, Sep 4, 2010 at 5:31 PM, Laurence MacNeill <
>>>> [email protected]> wrote:
>>>>
>>>>> So...  With all this discussion of printing from Flash Player and
>>>>> whatnot, it seems almost certain that we're going to have to switch to
>>>>> AIR...
>>>>>
>>>>> Has anyone here ever taken a fairly mature app from Flash Player to
>>>>> AIR?  I'm certain it can't be as simple as checking the "AIR App" button 
>>>>> in
>>>>> the FB4 Project Properties window -- there must be something else (or many
>>>>> things) that I'm going to have to change/adjust/re-write...  The app
>>>>> currently interacts a great deal with our CF server, and I'd imagine 
>>>>> that's
>>>>> going to have to change somehow, yes?  User authentication would probably
>>>>> have to change as well, I would assume?
>>>>>
>>>>> Can anyone offer any advice along these lines?  If anyone here has ever
>>>>> done what I'm thinking about doing, please let me know about your
>>>>> experiences.
>>>>>
>>>>> Thanks,
>>>>> Laurence MacNeill
>>>>> Mableton, Georgia, USA
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>  --
>>> Darin Kohles
>>> Adobe Certified Developer
>>>
>>
>>
>>
>> --
>> Scott Talsma
>> CTO, echoEleven
>>
>
>


-- 
Scott Talsma
CTO, echoEleven

Reply via email to