CiaN:MinDMaP the experience of reading those pages altered my anatomy

1Apr/112

MTS 4G Network APN

For those of you who may wipe your android phones, or develop on them, you may find that at some point you've forgotten to save your APN information.  You can either call MTS to get this, or search Google, and find it here:

Name: MTS
APN: sp.mts
Proxy: Not Set
Port: Not Set
Username: Not Set
Password: Not Set
Server: Not Set
MMSC: http://mmsc2.mts.net/
MMS proxy: 209.4.229.90
MMS port: 9401
MCC: 302
MNC: 660
Authentication type: Not Set
APN Type: Not Set

Good luck.  There was another one, but they didn't enter it properly, I will follow up with them and edit this post when I have it.

(edit) here's the second one:

Name: MTS
APN: wap.mts
Proxy: Not Set
Port: Not Set
Username: Not Set
Password: Not Set
Server: Not Set
MMSC: http://mmsc2.mts.net/
MMS proxy: 209.4.229.90
MMS port: 9401
MCC: 302
MNC: 660
Authentication type: Not Set
APN Type: Not Set

Bookmark and Share
Tagged as: , 2 Comments
5Nov/103

#Winnipeg GPS Bus Shedule Update

I have now completed learning all of the Android functionality that is required to make the GPS Bus Schedule "Go". These include:

  • Interacting with the OS, learning what an Activity, and Service are
  • Interacting with the GPS/Network location provider, learning how to 'smooth' the data feed from it
  • Interacting with the Google API, used to identify Locality, and Long / Lat
  • Interacting with the outside world directly, eg. Winnipeg Transit's API

In order to make this project able to work with many other Transit API's, I'm designing it to be modular, selecting the appropriate module based on the currently detected city. What this means is that I need to build a model that will standardize the flow of information between the presentation layer (UI) and the data access layer (API).

It will work something like this

Currently I'm working on the Model portion, I'm looking at various Transit API's and finding the most common data objects and attributes. Out of those I'm selecting the ones that I believe will be relevant to this project. Once I am complete, I can use this model as a common 'intermediary' to ensure that changes to the transit API's don't require User Interface changes, which should make this project much easier to maintain.

In case you're interested, I'm currently working in Eclipse 3.5, with Visual Paradigm as my modeling tool. The nice thing about this combination is the model-code-model loop is all integrated between the two, meaning changes in either my code or model are synced without data loss. Once I'm further along, I will post more, thanks for listening!

A snapshot of my development environment

Bookmark and Share
19Oct/101

Mobile GPS Bus Schedule

Lately I've been teaching myself to program Android applications. So far, the IDE is much easier to understand and work with than the Blackberry one was (referring to a few unfinished projects there, specifically my pizza order app).  I was recently discussing the possibility of the city opening up it's data with open API's such as SOAP with some of the Mayoral candidates here in Winnipeg (Rav Gill and Judy Wasylycia-Leis).  In doing so, it came to light that the Winnipeg Transit has in fact already done this, though it's still in beta.

The API is straightforward, and object oriented, below is a list of the objects that I will have access to:

Looking at the Stops object, it appears to be very simple to pass GPS long and lat co-ordinates to the object to retrieve a list of stops within the vicinity of the phone.  Once the user selects the stop (probably the closest one) I can query the stop schedules object, to get a list of routes and times.  Further selecting a single route will display a longer more detailed schedule for that route.

I'm confidant that this app will be fairly easy to create. Over the next few weeks I will be working on the use cases and object designs, and probably a lot of code.

One idea that was already passed to me (thanks Brian) was to ensure that the data access layer of the app was generic, enough such that it could easily be ported to other cities like Calgary, or Vancouver. Being that it will all be in Java, that should be fairly easy to do, if it's designed correctly. I'm thinking of having data access objects that could take a configuration file, and have the app select the appropriate one depending on the city that it is detected as being in.

If anyone has any ideas of features that they might like to see in this app, let me know and I will see if they fit with my vision. I'll get a Google Code site up soon, to manage bugs and feature requests. And yes, I will create it with the fact in mind that eventually it could be ported to the Blackberry.  And no, I don't care about the iPhone.

Bookmark and Share