Tag Archives: mark

Live from TSSJS – Spring Messaging with Mark

Posted on by
1

I’m live blogging from “Message Driven Architecture with Spring” by Mark Fisher at TheServerSide Java Symposium.  Mark talks about how Spring messaging involved with the idea simple POJOs, similar to JMS.  Mark’s examples involve RabbitMQ, as one of the more recent and powerful messaging providers.  Below are some notes for this talk.

1.  AMQP
Mark introduces Advanced Message Queuing Protocol, AMQP for short, protocol as an alternative to standard JMS messaging but with a richer feature set including an advancing system of binding for filtering/routing of messages.  Also, AMQP templates are very similar to JMS templates.  Mark presented a number of slides with code examples of AMQP using the templates.

2.  MailSender
Mark presents MailSender, which can be used to send simple mail massages. 

3.  Lifecycle Management
The Spring SmartLifeCycle has been created in Spring 3.0 to help facilitate auto-start and graceful shutdown of listeners with the rest of the application.  This feature includes an optionaly isAutoStartup() attribute which can be used, for backwards compatibility and maintenance, to disable this feature.  By graceful shutdown, the components are stopped in the reverse order of startup, as needed.

4.  Task Execution
Create managed and pooled tasks that don’t need to be started manually (a big no-no)

5.  @Async
Async was added in Spring 3.0 that uses the @Async annotation for executor framework.

6.  Task Schedule
Built-in framework in Spring 3.0, no longer requires Quartz scheduling plugins and similar structures.  Supports recurring and cancelable tasks.  The @Scheduled(“*/5 * 9-17 * * ?”) annotation allows developers to build cron-like schedule tasks.  There is also an alternative solution to externalize the schedule information in XML so it’s tied to the code and the code does not require import statements for the annotations.  Finally, it supports meta-annotations that uses the @Scheduled annotation but points to XML reference in another location.

7.  Message Publishing Interceptor
Send message a by-product of another event.

Conclusion
Mark covered a large variety of material in a very short time, so I wasn’t able to write all the important points from his slides.  He did demonstrate a number of really useful features available in Spring 3.0 and showed how messaging in Spring has really grown to a more mature development platform.  He presentation was especially good because he managed to include demonstrations of the code alongside the spec information.

Live from TSS-JS – Mobile Development with Mark

Posted on by
3

Currently attending “Comparing, Contrasting, and Differentiating Between Mobile Platforms” by Mark Spritzler, a fellow CodeRanch moderator.  The presentation is in part an open discussion with the audience of what people have tried and works well in the Mobile environment.

1.  What is out there?

  • Android OS (Java)
  • Apple iOS for iPhone/iPod/iPad
  • Web applications with custom UI for mobile applications.  CodeRanch currently offers a mobile web version of the website
  • J2ME (not common)
  • BlackBerry (custom Java)
  • SymbianOS (C)

2.  Android OS Review
Built by Google and uses Java and can run Flash.  UI built with declarative UIs using XML primarily and supports visual tools such as Droid Draw and/or Interface Builder.  MVC-like architecture with view as XML, and control/model as Java classes.  The API is quite open so there’s a lot of ability to customize for developers.

There is currently a large variety of Android devices so splintering of the code base could be in the future.  Some devices cannot upgrade the Android OS, leading to permanent branching of code base.

Also, Android requires a lot of manual work to integrate with a database, such as SQL Lite, whereas Apple iOS has this built in.

3.  Apple iOS Review
Built by Apple and uses Objective-C, and cannot run Flash.  Developers must manage memory manually.  The API is completely proprietary and there are limit tools for developers.  For example, the developer must have a Mac and use an xCode.  Closed APIs but Apple promises stability (although it did change in iPad with split/view feature).

Dicussion on Apple’s strigent application approval process followed.  One participant commented that they waited 1-2 months for Apple to approve it.  Apple has also stopped approving ‘pointless’ apps.  I asked Mark if he thinks the delays are worth the improvement in quality, to which he replied that it does lead to better applications.  He also informed the audience that Apple wants you to use certain visual controls in particular manners to help build a consistent UI, and may reject applications based on improper usage.  Apple sometimes comments on why applications are rejected but not always.

4.  J2ME Failure Review
Idea was to develop using Java and runs on a variety of devices.  One of the major problems is Sun certified J2ME mobile phones that didn’t properly or fully implement the spec.  Also, lead to splintering of code base and very inconsistent results across devices.

5.  Native vs Web applications
Web applications have greater reach since they can run on many devices, but have weaker performance and require the developer to self-promote them.

6.  App Generating Frameworks
Build mobile applications from predefined templates using a CMS system often entered in a web browser, such as MobileRoadie, but it is a paid service.  Builder frameworks (often open source) that generate mobile applications based on existing code including Appcelector, Rhomobile, PhoneGap.

Write once and run on many devices through generation.  They may have limited functionality since they use a subset of features available in the language.  Multi-touch is also very limited in Android over iOS.  HTML5 does support location-aware so it can help in application generation.

Conclusion
Mark ended the presentation with an open discussion asking people to share their own mobile development experience.  He pointed out that there a lot of pros and cons to using different mobile platforms and mobile devices, and you should consider the resources on hand when deciding how to proceed in development.