On Sun, Jul 12, 2009 at 9:46 AM, Mark Ellis <m...@mpellis.org.uk> wrote:
> On Sat, 2009-07-11 at 13:35 +0200, David Eriksson wrote:
> > [Sorry for dupes of this.]
> >
> > Hi,
> >
> > First of all, it's wonderful to hear that you make good use of SynCE. I
> > would really appreciate if you are able share some more about the
> > context you use SynCE in, either to the list or privately. (It's great
> > to see one's kids grow up
>
Sure thing. So Flexilis is a mobile security company that cares a lot about
testing. Writing cross-platform mobile software takes a great deal of care
considering there are so many different OS's, resolutions and input devices
(keyboard, touch screen, etc). We use a continuous integration server and
already have some great tests (in the form of self-contained exe's). Not
satisfied simply running unit/integration tests inside the WM emulators, we
also deploy them to all the development devices we have. SynCE makes this
possible, as it allows us to have one linux server with hundreds of USB
devices attached to it. I use Ruby::DL wrapping librapi.so to copy the
executable over, run it, wait for it to complete and read the output file
and report back to the CI server the results (what failed on what devices).
This is all up and running and working great!
To run acceptance/gui tests, I've created a device side DLL that wraps many
of the WM coredll methods. This is where the need for CeRapiInvoke came
into play. Using my device side DLL, with bindings to librapi, I'm able to
write GUI tests in ruby lightning fast. To give you an idea of the power,
I'll include a short little program here :)
phones.each do |phone|
phone.copy_to("MyCab.cab", "/Windows/AppMgr/Install/MyCab.cab")
phone.key_press(HOME)
phone.execute("wceload.exe")
assert(phone.get_foreground_window.get_window_text == "Installation")
phone.push_button(OK)
end
Of course, this is just a sample but I think you get the idea.
>
> >
> > I think that you should model the new RAPI interface after the Microsoft
> > RAPI2 Interface (IRAPIDevice, IRAPISession, etc):
> >
> > http://msdn.microsoft.com/en-us/library/aa922133.aspx
> >
> > MS buils these interfaces on top of the Component Object Model (COM) so
> > C++ would be a natural fit, but if you implement it in C for easier Ruby
> > bindings that's fine. Just add "this" (or "self" :-) as first parameter.
> > (I would have implemented the original librapi2 in C++
>
> I'm glad you didn't, I probably wouldn't have bothered fiddling with
> it :)
>
> > if it wasn't
> > because I hoped that language bindings would be easier with a C
> > interface.)
> >
> > In the C interface I suggest that you do like this, or something close
> > that makes it easy for the Ruby bindings:
> >
> > HRESULT RAPIDevice_CreateSession(
> > RAPIDevice* self;
> > RAPISession** ppISession
> > );
> >
> > BOOL RAPISession_CeCopyFile(
> > RAPISession* self,
> > LPCWSTR lpExistingFileName,
> > LPCWSTR lpNewFileName,
> > BOOL bFailIfExists
> > );
> >
>
> David, this is a magnificent idea ! And it's relatively easy to
> implement I think.
>
> David (Richardson), if this sounds of interest, here's how I would see
> this working.
>
> Currently all rapi calls start in rapi_indirection.c, where the current
> context is fetched, and used to call the appropriate function, in rapi/
> or rapi2 subdirs, through the rapi_ops struct. Initially we change the
> "real" functions in these subdirs to accept the context as the first
> parameter, which we pass through from the call in rapi_indirection.c. At
> this point the original API is intact, but we have a working body of
> functions that accept any context we pass.
>
> Now it should be possible to implement a new public API in the manner
> David shows, that can call these functions using the context from the
> RapiSession pointer we pass. Does that make sense ?
Well now I'm extremely glad that I decided to bounce this off the list first
before giving it a go. This insight will make things a lot easier!
>
>
> I think I'm going to give this a go, though I want to do another release
> first, so it won't be straight away.
>
> > Locking (per session) should really be done inside the RAPI calls, not
> > outside.
> >
>
> Yes, I think each context needs internal locking, but I'm not sure how
> this should be done. Can we just use pthread mutexes ?
>
> > Reference counting could be implemented just like AddRef and Release
> > from IUnknown in COM... :-)
> >
> >
> >
> > Best regards,
> >
> > David Eriksson, http://www.divideandconquer.se/
> >
> >
> > On Fri, 2009-07-10 at 17:06 -0700, David Richardson wrote:
> > > I'm using librapi for some really cool testing framework stuff at
> > > Flexilis. I'm really trying to push the limits of the library. I've
> > > wrapped librapi in ruby using Ruby::DL but currently I have to mutex
> > > on any RAPI call. I'd really like to only have to mutex per-device.
> > > Ruby only uses green threads so the existing thread safe stuff isn't
> > > going to help me, I believe. I want to run tests on hundreds of
> > > devices in parallel.
> > >
> > > What I want to do is create alternative wrappers for each RAPI
> > > function where I pass the context in as the last parameter, rather
> > > than specifying it ahead of time with . I tried some initial
> > > experimentation with this yesterday, but didn't have much luck.
> > > Before I dive too deep into it, I wanted to make my proposal and hear
> > > any comments you have. Specifically I'm concerned about how the
> > > contexts work and when/how they become invalidated.
> > >
> > > Serially I will create each connection (rapi_connection_from_name),
> > > select it (rapi_connection_select), initialize it (CeRapiInit) and
> > > store the current context (get_current_context). Then in parallel I
> > > will call modified RAPI functions on hundreds of devices that take the
> > > context in as a paramater.
> > >
> > > I notice that the act of selecting a connection unref's the previously
> > > selected connection and destroys it (since this was the only
> > > reference). Is it sufficient for me to just store a reference to each
> > > context and call rapi_context_ref (and unref when I'm done)? Is there
> > > anything else that would invalidate the previous context?
> > >
> > > I'll hopefully be experimenting with this sometime next week. Is this
> > > a change that others would be interested in contributing toward
> > > librapi's trunk? Do you have a suggestion of a better way to go
> > > about this? Is there maybe some existing functionality that I'm
> > > missing that already allows this?
> > >
> > > Thanks!
> > > -David Richardson
> > > Flexilis Mobile Security
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Enter the BlackBerry Developer Challenge
> > This is your chance to win up to $100,000 in prizes! For a limited time,
> > vendors submitting new applications to BlackBerry App World(TM) will have
> > the opportunity to enter the BlackBerry Developer Challenge. See full
> prize
> > details at: http://p.sf.net/sfu/Challenge
> > _______________________________________________
> > SynCE-Devel mailing list
> > SynCE-Devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/synce-devel
>
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
SynCE-Devel mailing list
SynCE-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synce-devel
