BlackBerry to Become Location-Aware

EddieC 0 430 Views

You don't have to have lived in Haight-Ashbury in the Sixties to achieve self-awareness in San Francisco. BlackBerry developers are gathered in the city this week for the annual , taking place now through Thursday. Among the top stories is a new service platform from Research in Motion that will enable developers to build location-aware applications that can include advertising, collect payments or generate other location-based activities or services. Maybe a text message will inform you as you walk past the that its just received a shipment of tie-dye shirts, for example.

Making it possible will be BlackBerry Advertising Service, which will allow ads to be integrated with applications, to generate revenue and to make mobile advertising easier, the company said. Set for availability next year, the service will include access to advertising networks such as those managed by and and to such as those managed by Navteq. It also will be possible, the company said, for ads to tie directly with BlackBerry features such as making a call, adding to the calendar or contact database or accessing BlackBerry's App World. Of course, reporting will include impressions, clicks, conversions and integration with the Omniture Web analytics system (acquired last month by Adobe).

One service available now only to top-tier developers is the , which next year will be opened up to all registered developers. It allows time-sensitive content and payload to be pushed to applications.

All the services and relevant SDKs are slated for availability by mid-2010.

Dani AI

Generated

Building on ’s conference summary, here are focused, practical notes for developers implementing location-triggered features so they work reliably, respect users, and avoid common pitfalls.

Start with privacy by design. Ask for explicit, contextual consent and offer a clear choice for coarse vs precise location. Minimize what you store: keep only the fields you need, rotate or truncate historic location data, and use short retention windows. Always transmit location over TLS and avoid embedding persistent raw coordinates in logs or analytics identifiers. Check and follow applicable privacy laws and platform guidelines.

Optimize for battery and unreliable networks. Prefer geofencing or significant-change listeners instead of continuous high-frequency GPS. Batch network operations and debounce rapid updates so the radio wakes infrequently. Fallback to cell/wifi-based positioning when GPS is poor, and use server-side geo checks for final decisioning to keep client work light. Example debounce pattern (pseudocode):

minInterval = 300000   // 5 minutes
lastSentTime = 0
buffered = []

onLocationUpdate(loc):
  if now - lastSentTime < minInterval:
    buffered.append(loc)
    return
  sendBatch([loc] + buffered)
  buffered.clear()
  lastSentTime = now

Test aggressively on real devices and in adverse conditions — low battery, airplane mode, urban canyons, and roaming. Simulate movement and verify end-to-end timing: trigger → delivery → user action. Instrument end-to-end latency and failure rates; use server-side validation for any monetization or attribution events and implement frequency caps to avoid spamming users.

Finally, design UX that sets expectations: explain why location makes the feature better, give an obvious way to opt out, and surface controls in-app. When integrating with any ad or commerce flows, read the SDK docs and terms carefully and keep monetization logic auditable on the server side.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview