LinkedIn Facebook Twitter bemoko blog bemoko technical pages
Tel: +44 1256 581028 Email: info@bemoko.com

Bemoko blog > java

21

Nov

The Camera API – More than just your name in lights!

Posted By Emily Nicholls Wednesday, November 21, 2012. No Comments

New mobile technologies are nothing new! Javascript geolocation functionality has become common place in mobile websites over the past 3 years, allowing a mobile site to pinpoint user location.

Other breakthroughs include sensory device capabilities.

“Accelerometers in mobile phones are used to detect the orientation of the phone. The gyroscope, or gyro for short, adds an additional dimension to the information supplied by the accelerometer by tracking rotation or twist.” – GSM Arena glossary (sensors)

Such sensors, inter alia, permit the user to control the device in new ‘never before imagined’ ways.

Probably the newest kid on the block, however, is the Camera API. This API gives the user the ability to take an image from their device’s camera and upload it to a mobile site. The possibilities are endless. For example, the uploaded picture could be used as the user’s avatar. A mobile site could facilitate the sharing of the image on social networks. But, being at mobile’s bleeding edge, we refuse to halt our imaginations there.

The most exciting innovations in mobile have always come through the collaboration of new mobile technologies with pre-existing services. For example, geolocation when coupled with readily available public APIs permitted not just location detection but location information. The user is now advised that Acme Plc’s nearest store is situated 5 miles away and is presented with a map detailing user and store location information plus driving directions.

And so it shall be with the Camera API. It’s most exciting uses shall emerge through innovation. What would happen if we coupled the camera API with the HTML5 canvas’ 3D rendering capabilities? One could imagine a spinning 3D bauble with the user’s face painted on it and light reflecting therefrom.

A festive treat for any web user. Or let’s twin the camera API with Google Maps, geolocation and a social network. We can now plot the user’s friends on a Google Map, detailing not just their current locations but using their latest uploaded photos as map pins.

The possibilities are endless.

Of course, the bemoko platform not only supports such functionality but seeks to enhance it. The bemoko platform, for instance, is readily used to dynamically transcode images received from the camera, making the photo web-ready for the accessing device both in terms of file size and image size.

Other issues remain. For example, the orientation of the image has proved a challenge, the device having no knowledge of which way up is the right way up.

bemoko, however, being experienced market leaders have everything needed to respond to such emerging concerns. The first ingredient is awareness – know your enemy – and the second item for the pot being the expertise to confidently tackle such issues. Yet more reasons why the bemoko choice is the right choice.

By Dan Lewis- Senior Developer

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Posted in: iphone, java, mcommerce, mobile, mobile design, mobile search, mobile technology, mobile UX, mobile web

18

Sep

4 Easy Steps To Mobile Web Payments

Posted By Ian Homer Tuesday, September 18, 2012. No Comments

Mobile has always thrived for applications where immediacy is paramount and retailers should not fall short of allowing the customer to complete their transaction whenever and wherever the customer may be. Waiting until the user is back at their PC may push your customer to connect with one of your competitors. Taking payments is not difficult, so let’s take a look at how you can take payment on your mobile web site and complete the customer’s journey.

Payment options at your disposal include:

  • Online wallets
  • Credit card – similar to what you might expect on a PC site
  • Direct operator billing – payment taken of the customers bill
  • Premium SMS (a.k.a PSMS) – SMS sent to customer that gets

Various on-line payment service providers, such as Bango, CellPoint Mobile, Braintree and PayPal provide hosted solutions that allow you to get up and running quickly for these different payment options. Note that service providers may not give you all of the 4 payment options above.

These hosted solutions work by taking the user to a payment page provided by the payment service provider so that payment can be taken. A typical flow for this is :-

  1. The user makes the product choices on your web site filling up their basket
  2. When the user is ready to purchase the products the user is directed the payment service provider page. This is typically by an HTML form that takes the user off your site, although you should be able to customise this page so that it looks like your brand.  If you decide to take payment details on your site rather than redirecting, be sure you understand the PCI compliance rules that govern storing credit card data.
  3. When the payment has been confirmed a back-end callback can be made to your web site to confirm the purchase is OK and the user is taken to a thanks page on your side. The callback is necessary to reduce chances of unscrupulous users fooling your site into thinking that the payment has been received.
  4. Your site delivers a thank you page AND sends out email or SMS confirmation to the user that the order is on its way.
  5. Note that the callback may occur in a couple of stages 1) payment has been authorised – i.e. funds reserved and 2) payment captured – i.e. funds transferred to your account. So do be ready to handle either of these signals – if you’re dealing time sensitive products, e.g. take away delivery, then you’ll want to put the order in motion as soon as the payment as been authorised. Otherwise you may want to hold off on putting the order in motion until you’ve had confirmation that the payment has been captured.

Note that Braintree has a nice variation on this where you can handle this payment integration with a javascript client library.

Do compare the commission that each of the service providers takes on each payment as this can vary significantly from one provider to another and from one payment option to another (e.g. credit card vs PSMS).

When it comes to 3D secure, the user experience has not yet been optimised for mobile, although it does work. If you choose to disable it then you may improve the user experience, but you will be taking the risk that payment is fraudulent since 3D secure does give you extra security for your payment.

As always – monitor your site. When you start taking payments, ensure that you monitor how much your site takes every hour and send out alerts if orders drop off during an hour.  This can be an early warning signal that something is misfiring.  If you are using a platform to deliver your site, such as bemokoLive, then these alerts and the monitoring come built in, making it much easier to ensure that every order gets fulfilled.

If you want to talk to us about how to start taking payments on your mobile web site and take use of some of our existing payment integrations modules then please get in touch, feel free to share or comment on this blog

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Posted in: business, iphone, java, mcommerce, mobile, mobile design, mobile search, mobile technology, mobile UX, mobile web, multichannel, public website news, responsive design, smartphone, social, tablet, transactional, web optimisation

12

Aug

GroovyWS, CXF and .NET webservices with an AuthHeader = pain

Posted By Mat Diss Thursday, August 12, 2010. 1 Comment

One of the joys of using the bemokoLive development framework is the ease with which you can integrate with external content services.  I’ve recently been working on a site which needs consume a .NET generated webservice.

For this integration, I decided to use GroovyWS which provides a very nice interface to the world of Apache CXF.    Setting up the webservice is simplicity itself:

proxy = new WSClient(WSDL URL, this.class.classLoader)
proxy.initialize()

This was all going well until I tried to use the login webservice call.  The login provides a token which is needed to authenticate all further calls to the webservice.  The XML returned from the webservice is:

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <AuthHeader xmlns="https://app.restaurantdiary.com/webservices/ReservationService/">
      <Token>string</Token>
    </AuthHeader>
  </soap:Header>
  <soap:Body>
    <LoginResponse xmlns="https://app.restaurantdiary.com/webservices/ReservationService/" />
  </soap:Body>
</soap:Envelope>

Notice that the token is returned in the SOAP header, not the SOAP body.  It seems that CXF is geared up for reading the body of the message only, getting to the headers is not simple.  So my problem was being able to get the token and add it to further calls.

I tried many searches of the internet, but it seems that either no one has ever had to do this or they have and didn’t write about it.  Hopefully the following example will help if you ever need to do this.  The following example is in Groovy.

Before I get to the actual example, let me take a quick diversion, but useful, diversion on logging.

I spent hours trying to see the SOAP request and response that was being sent and received, using network sniffers and the like.  Communicating over SSL also meant I was doomed to failure.  Then I discovered interceptors, notably the LoggingInInterceptor and the LoggingOutInterceptor.  This simple piece of code allowed me to log the incoming and outgoing requests

proxy.client.getInInterceptors().add(new org.apache.cxf.interceptor.LoggingInInterceptor())
proxy.client.getOutInterceptors().add(new org.apache.cxf.interceptor.LoggingOutInterceptor())

I still didn’t have my AuthHeader though.  After a lot of experimenting, I found I could access the headers with this piece of code

def headerList = proxy.client.getResponseContext().get(Header.HEADER_LIST)

This was good.  Accessing the auth token was fairly simple after that:

SoapHeader sh = headerList[0]
 def doc = sh.getObject()
 def list = doc.getElementsByTagName("Token")
 token = list.item(0).getFirstChild().getNodeValue()
 log.debug("Token = " + token)

Yay, token now safely stored in my variables…. Now to add the token to future headers

List<Header> headers = new ArrayList<Header>();
SOAPFactory sf = SOAPFactory.newInstance()
def authElement = sf.createElement(new
QName(namespace, "AuthHeader"))
def tokenElement = authElement.addChildElement("Token")
tokenElement.addTextNode(token)
SoapHeader tokenHeader = new SoapHeader(new QName(namespace, "AuthHeader"), authElement);
headers.add(tokenHeader);
proxy.client.getRequestContext().put(Header.HEADER_LIST, headers)

This code adds the auth header with the token into the SOAP headers for every future request.

Hopefully if you are trying to use SOAP headers with CXF, this post will save you some time.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Posted in: java, mobile

20

Mar

Quick step-by-step guide : Upgrading Junit 3.x to Junit 4.x

Posted By Ian Homer Friday, March 20, 2009. 2 Comments

Well we finally got around to upgrade all our unit tests to new features. About time really!

We use maven and the maven-surefire-plugin for running our unit tests during our build process. Let’s look at the steps I did to get migrate.

  • All our test cases extend from a single abstract test case class called AbstractLiveTestCase that in our Junit 3 integration extended from junit.framework.TestCase. For Junit 4, tests are described with annotations so we don’t need to extend this class anymore – so I (1) removed the “extends TestCase” from our AbstractLiveTestCase
  • The Junit 3 TestClass class used to provide all the handy assert functions. These are now provided as org.junit.Assert static methods so I went through each of our tests and (2) added “import static org.junit.Assert.*;” to the top of each class. With the handing auto source code formatting in Eclipse enabled, Eclipse automatically expanded the “org.junit.Assert.*” imports to the explicit ones needed for that class when I saved it.
  • And finally (3) Added @Test to each test method so that Junit would know what tests to run.

Basically that was it – surefire/maven/junit picked up the test cases in the new style – and in most cases that’s job done. However we wanted to go a little further.

We had also implemented in Junit 3 a handy feature that outputted a quick ERROR message in the system out of a test run so we could quickly see the failure. By default maven’s surefire simply tells you there was a failure, but you have to look at a file to see what it was. Bit of pain that, so in our Junit 3 extension we would provide more info on the screen when a failure occurred, for example we might see something like:

Running com.bemoko.live.platform.mwc.sites.LiveSiteTestCase
ERROR : *** Test Failure *** Site home not correct expected: but was: @ line 17 of com.bemoko.live.platform.mwc.sites.LiveSiteTestCase (com.bemoko.live.platform.BemokoTestListener)
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec <<< FAILURE!

In Junit 3 we did this by overriding the runTest method of the TestCase class. In Junit 4 we can use runners and listeners. To start with we set the @RunWith annotation on our AbstractLiveTestCase to indicate that all of our tests should run with a specified runner …

@RunWith(BemokoTestRunner.class)
public abstract class AbstractLiveTestCase {

The runner was defined to register a listener …

1
2
3
4
5
6
7
8
9
10
public class BemokoTestRunner extends BlockJUnit4ClassRunner {
	public BemokoTestRunner(Class<?> clazz) throws InitializationError {
		super(clazz);
	}
	@Override
	public void run(final RunNotifier notifier) {
		notifier.addListener(new BemokoTestListener());
		super.run(notifier);
	}
}

and the listener was defined to listen for failures …

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
public class BemokoTestListener extends RunListener {
	private static Log log = LogFactory.getLog(BemokoTestListener.class);
	@Override
	public void testFailure(Failure failure) {
		Throwable t = failure.getException();
		if (t instanceof Exception) {
			log.error("*** Test Failure *** " + t.getMessage(), t);
		} else {
			if (t.getMessage() != null) {
				log.error("*** Test Failure *** " + t.getMessage() + " @ "
						+ getErrorLocation(t.getStackTrace()));
			} else {
				log.error("*** Test Failure *** ", t);
			}
		}
	}
	@Override
	public void testIgnored(Description description) {
		if (log.isWarnEnabled()) {
			log.warn("+++ Test ignored +++ " + description.getDisplayName());
		}
	}
	private String getErrorLocation(StackTraceElement[] st) {
		for (StackTraceElement ste : st) {
			if (ste.getClassName().startsWith("com.bemoko")
			    && !ste.getClassName().contains("AbstractLiveTestCase")) {
			  return "line " + ste.getLineNumber() + " of " + ste.getClassName();
			}
		}
		return "(line number and class not known)";
	}
}

in this way I can handle events from my tests in any way I see fit and much more elegant that the Junit 3 implementation I previously had.

Job done and we’re all sorted for our unit test framework for the foreseeable future.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks

Posted in: java