Refactoring the MMI contribution

1. Refactoring the MMI contribution Extending the look and feel

2. Reasoning • The original contribution from EchoStar works well and meets MMI requirements • But • Couldn’t easily be re-skinned • Behaviour could not be tailored • Wanted to use elements elsewhere in the Stack • Very useful basic HTML renderer

3. The Standard MMI display The standard display when a single MMI message has been received.

4. The Standard MMI display, thrice How the display looks after three MMI open messages have been received.

5. The Alternate MMI Display A quick re-skin later, and the display looks like this.

6. Redeployment – basic When an error is detected in the CableCARD communications, we can display this OSD.

7. Redeployment - advanced The HTML renderer is now under control of a diagnostics application.

8. What was changed Original Rework HTML rendering now in MiniBrowser.java with useful interface Data fetched from abstract UrlGetter Dialog now separate entity Added mmi and ui classes to allow inheritance • HTML rendering in HTMLComponent.java • Data always fetched from CableCARD • Dialog was part of MMIDialog • Flat class structure

9. Basic Class Diagram

10. How can I add my own? • Controlling the display • Extend DisplayManager and implement these methods • displayDialog() • dismissDialog() • Implement [if required] MiniBrowserListener to receive updates in the HTML • contentUpdated() • Have your own paint() • Otherwise, it won’t look at all like you thought • Create the extended DisplayManager • You’ll have to override & extend SystemModuleMgr to instantiate an extended SystemModuleRegistrarImpl that creates your new DisplayManager class

11. ...and... • Extend ResidentMmiHandler if you want different behavior. • We did this to enforce a single dialog • Utilize the methods in MiniBrowser to display help prompts: • hasLinks() • true if the HTML page has a link that can be selected • isScrollable() • true if the HTML page is bigger than the window • hasHistory() • true if the user has selected any link and therefore can go ‘back’ in the browse history. • Cleared when navigate() is called • Use navigateBackwards() when back key is pressed

12. Extended Class Diagram

13. Word of warning • The MMI display behaves like a ‘Well Behaved Application’ • i.e. It informs of focus stolen • But! It doesn’t listen for focus lost • This means that if you decide to remove the ability to clear the MMI display, you may find yourself in a whole new world of hurt as you try to restore focus to the application...

14. Using the MiniBrowser elsewhere • Simply create one and give it the data! • OK, an example: UrlGetterurlGetter = CableCardUrlGetter.getSession(); MiniBrowser browser = new MiniBrowser(urlGetter); browser.registerMiniBrowserListener(this); // we implement MiniBrowserListener // Now fetch the Applications from the POD... And then PODApplication application = <PODManager>.getApplications().[<index>] // Set the browser size and color, setBounds(), setBackground() etc. // Add the browser to your own Container / Component this.container.add(browser); // And navigate to the app URL browser.navigate(application.getURL()); • Don’t forget to add key passing public void chUpKeyAction() { browser.scrollVertically(MiniBrowser.SCROLL_UP_1_PAGE); } public void selectKeyAction() { // Doesn’t matter if one is not selected, will call contentUpdated() browser.followCurrentLink(); }

15. Questions

16. Thanks • EchoStar for the original contribution • @ NDS • Tom Gwozdz • Laurentiu Dragan • Madhusmitha Gottipati • Bigi Porinju • @ Cablelabs • Steve Maynard • @ Comcast • Khurram Qureshi

17. TDK Test Development Environment.

18. TDK (Test Development Kit) • The TDK was created so that Comcast could do integration testing on the RI set tops. • The TDK runs on a computer/set top environment. • The TDK is built using Maven. • There are two parts to the TDK; the TDK server(Run on PC) and the TDK app which is run on the set top. • The TDK uses TestNG for its reporting and maven for its execution. • The TDK server tells the TDK app what tests to run and where to get the test classes over a UDP socket connection. • The TDK works on top the Comcast CATS framework .(Comcast proprietary software)

19. NDS Contribution to the TDK • NDS has implemented over 500 test cases • Tests around • Tuning • Recording • User key presses • Time Shift Buffers • Trick Play • DSMCC downloading • Section filtering • Channel maps • Performance • Graphics • …….

20. After the TDK is built. Build The TDK. • mvn clean install : build the entire TDK and run all the tests. • mvn clean install –DskipTests=true : Just build the TDK • You can execute individual test cases with the following command • mvn test –Dgroups=TC0003,TC0006,…. • Or execute the entire suite • mvn test

21. TDK Execution. • TDK tests start to execute. • TDK server opens socket to set top running TGShellapp. • TDK tells TGShell app what test class to run and where it can find that class file. • TGShell executes the class file and reports the results. • Once the TDK run finishesthe TestNG results can be foundin test/target/surefire-report • A detailed report with the testpasses/failures exists there.

22. What is TGShell. • TGShell is the app that is run on the set top. • All TGShell does is when launched opens a socket and waits to be told what to do. • TGShell receives instructions from that open socket and creates class files to be executed from those instructions. • TGShell then sends back the results of the execution over the socket connection.

23. CI with Hudson. • With Hudson the RI can be built on a fixed schedule or even monitor the SVN/CVS/GIT…. Repoisitory for updates which will then trigger a new build to be preformed on the new src code. • If the RI build is successful another project can then be triggered lets say the TDK to then test the new build. • All automated with build artifact/Test results archiving that can be retrieved at any time.

24. The End….. • Demo • Q & A time 

25. Version control with Git and Gerrit A different way of working with the RI

26. Question Who has used Git at work or home before?

27. What is Git • Git is a distributed version control system (DVCS) • It’s non-centralized nature makes it ideal for loosely coupled, widely distributed projects • Git was originally developed by Linus Torvalds for versioning the Linux kernel • Now used by a growing number of projects in both open and closed source communities • Git is itself an open source project • Available as source code under GPL • Pre-built packages for all common platforms • Free as in freedom, and free as in beer!

28. What is Gerrit • Gerrit is a web based code review and repository management tool for Git • Gerrit is developed by Google and is used for the Android project • Gerrit is an open source project and is available as a deployable .war file • For an example have a look at the Android Gerrit • https://review.source.android.com

29. What is wrong with Subversion? • Nothing, it’s just not the best tool for this job • SVN works in a very centralised, server dependent way • SVN cannot import from other SVN repositories • Except by using patches, but svn diff is very limited • SVN has poor support for branching and merging • And every now and again SVN gets confused and refuses to let us commit – normally when we are trying to release

30. What are the advantages of Git • The biggest strength of Git is it’s distributed nature • Not dependant on a central server • Once the initial clone is complete network access is only required for updates and delivery • Great for offline working • Bringing in changes from other repo’s is normal work flow • Branching and merging are easy • Understands SVN • Reliable – doesn’t break it’s own repo • Well, it hasn’t yet…

31. Our set up • Although Git does not require or enforce a central server it is good to have a definitive repository for releases and work tracking • The work is not done until it’s in the definitive repository! • We use Gerrit for code reviews and to manage our repositories

32. External Cablelabs SVN Git repositories SVN Mirror Main Feature NDS SVN To be retired Gerrit Developers

33. Benefits • Easy merging of Cablelabs commits into our code base • Much better support for feature development • Separate branch per feature • Update the branch from the main line regularly • Easy merge back of the feature once complete • Enforced code reviews • And a guarantee that what is reviewed is what is committed

34. The Future

35. Cablelabs support of Git • Cablelabs are currently looking at adding support for Git • Initially along side SVN • Then maybe longer term moving across to Git completely • The benefits for third parties of this would be • Easier merging of releases • Better visibility and tracking of fixes • It will also allow us to simplify our set up

36. External Cablelabs SVN Git repositories Cablelabs Git Main Feature Gerrit Developers

37. Improving the contribution process? • Suggestion • If Cablelabs were to have a public Gerrit in the same way the Android project has, then third parties could contribute fixes and features directly as a code review. Cablelabs and other interested parties could review and comment on the submission prior to it’s acceptance.

38. Any Questions?

39. SNMP Implementing ECN-1114 *

40. * and a few other things

41. The reasoning • ECN-1114 simply states that Applications should be able to query MIBs where data is supplied from the Stack. • Or the Platform • Or another Application • Or, come to think of it, the ECM • But that’s not 1114 that’s 1138 isn’t it? • And there’s probably an SNMP server in the Platform • Aargh. • So that’s easy then.

42. The setup • We put an SNMP Master Agent in the Platform • We open up Agent X on the Master • We put an Agent X client in the Stack • All the applications register with the Stack, we register via Agent X with the Master • All the Stack handlers register in the same way • The Platform supports queries with its own Agent X client • We use snmp4j to do this • Cup of tea and a biscuit, job done

43. The sting • Whadja mean “snmp4j doesn’t work in the RI”? • Oh, I see, it wants a full J2SE 1.4.2 JVM because it makes extensive use of nio • So let’s go find an open source SNMP client we can use... • That we can use. • And would run on PBP 1.1 – Not J2SE 1.5 • We can use. • And didn’t upset our lawyers quite so much • Eventually, Hello to the University of Coimbra • And Drexel University

44. The fun • Drexel’s SNMP implementation was OK. • We needed to wrap it up a little in case the lawyers decided we couldn’t use it, and therefore we wouldn’t impact the rest of the stack. • But, all in all, it handled ASN.1 BER data pretty well. • UoCj.AgentX • Bit of a student project, shall we say • Lots of examples of Java coding • At times, it would almost work • Got a serious refactoring

45. Serious Refactoring

46. And then • Having gotten the SNMP framework in place in the Stack, along with a simple SNMP Master in the Simulator Platform, we had to add the ability to register MIBs with that framework. • There is a function in MIBRouter that can add OIDs to the router, but they don’t quite support query, table indexing etc. • So, in a slightly more serious vein, here’s how to add your own data sources. • But first a slight detour...

47. Block Diagram

48. The Objects you can use

49. A Leaf Handler • A Leaf Handler is one that supplies a single value for a single OID • Each OID is treated independently • You can’t provide the base-OID of the group and have the framework pass all requests to you • The ABC LeafMIBModuleHandler provides the base functionality; your class must provide • SNMPResponseprocessGetRequest(SNMPRequest r) • String[] getOIDs() • You should also implement MIBModuleHandler as that is used in dynamic registration • registerMIBObjects() • Currently, Leaf Handlers are Read Only handlers as there are no MIBs that can be set within the Stack.

50. processGetRequest(SNMPRequest r) • This simply passes the SNMP Get request to your handler. • You find the OID requested from • r.getMIBObject().getOID() • You return the value as an SNMPResponse