ionicmobile / appsteamkanban Goto Github PK

import and test with all apps
Pay close attention to SSO across different apps

There is a demo environment that has a static version of the server code that will continue to support Nucleus and Insight as the server code continues to evolve. We need to publish versions of Nucleus and Insight to this environment that work against that server code.

The easiest way to solve this is probably to build the master branches of these apps in Xcode 4 and deploy them to that environment.

Apps are at http://demo.ionicmobile.com/app_store

server @ demo.ionicmobile.com/app_store
user:capistrano
var/rails/ionic

Podium (on dev)
AppStore (on dev)
Assets (on dev)
Radar (on dev)

Remove Insight from demo.ionicmobile.com environment App Store

Choose one app and modify it to import framework and build using COCOA pods.

Maybe remove dependencies that framework has on submodules if necessary.

Fix my spelling of COCOAPods if it's wrong.

Currently, all Ionic Apps require magnet and login images to be included in the apps. We should try to make these part of the framework package so that there is less setup required to have the framework "just work"
This will probably involve including the images in the bundle.

Update provisioning profile for any apps that don't work on the demo.ionicmobile.com environment

Finish
https://github.com/ionicmobile/story-kanban/issues/124

• Update API on completion of the story

Mark had trouble using Podium on his Android at the last company meeting. Look into why authentication might not be working in production (or development).

Pretend to be Billy Intern

Try to set up the Ionic Server on a local Apple running OS X

Can you get to the admin screen?
Can you create users?
Can you set usernames and passwords?

Do it again on Ubuntu, CentOS, and Redhat (maybe)

Document any missing documentation that leads toward this process and encapsulate all of the required files in a local folder. Maybe burn it to a CD!

The goal is to assess gaps, don't spin on anything for too long. Note issues in the comments of this story.

On a clean mac alpha test the soft and look for issues or quick fixes that can be done before "Beta"

Build for release and point to staging

This has been determined to be a relatively large IE Javascript bug in IE8. IE9 also has an IE Javascript bug, but it is less large. IE10 works fine. We've asked the customer if upgrading is a potential solution.

Updates to the server side of the framework that will go out with the next release break Neucleus. So it needs to be removed from the Production App Store before that happens (or concurrently).

Build Neuclus against iOS6 SDK with a working Provisioning Profile and deploy to demo.ionicmobile.com so that it works for the sales team.

List environments and what they're used for in a clear shared location

do story #41 again now that all the apps are pointing to staging.

Since IMAppDelegate is deprecated, apps are no longer setting their bundle name and version number in the keychain. This breaks the app service being able to know what is installed.

We will move the call from IMAppDelegate into the initer for the framework to replicate the old functionality of asserting the info in the keychain on app launch.

AC:

• Initing the framework writes app name and version info to the keychain. this should be visible in Dev Console, as well as in a working app store.

blocked on
https://github.com/ionicmobile/Radar/issues/484
https://github.com/ionicmobile/IonicAppStore/issues/89
https://github.com/ionicmobile/assets/issues/683

Make sure you can build
Make sure the documentation builds correctly
Zip up source code and documentation and put it up on geonosis or in Assets
Email Adam Axe and Mark with an email letting them know the status when complete
Please run the email by Wes before sending (or call if Wes is not around)

• wipe a device and load up radar.
• login and change the url to mobiledev

Build for release and point to staging

Build for release and point at staging

Pretend to be Billy Intern, with a locally running Ionic Server, try to do the following:

Assuming a successful locally running server...

1. Compile and Run the provided App Store code
2. Walk the user through creating a basic Ionic App that logs in and shows a green screen (template is available in the dev Framework repo.
3. Once you get the app built, try to add it to the app store

Document this process, and encapsulate all of the required files on the Alpha USB Stick

Let's fix this!

We've had this concept of an "Appstore Story" that walks the user through setting up a server, building the app store, and uploading their sample app. This feels unnecessary, but it does feel like we might be missing something from the documentation that presents the "big picture". Look through the documentation with this kind of "big picture" gap in mind and propose a way to solve that problem or verify that it's not a problem.

I know this story is nebulous, so feel free to reject it if you don't see the need for it. I'm 50/50 on it right now, but I want someone else to check my gut.

• Assess amount of work required to work in iOS7

Note that this does not include updating to the latest framework.

Check which server it is pointing to. If it's not pointing to Mobile-dev mention it to team!

Currently we have a framework initializer that is only usable by Asynchrony developers (initWithDefaultHostInformation). The feeling is that this dirties up the framework because the framework points to a hardcoded production URL when you use this. We would like to simplify this initialization to mean "use dev console/apiHostInKeychain", and make it so that if you want a hardcoded host you should use one of the other init methods. Let's do this!

-Wes

As part of the 2.0 release we will be presenting a CD with the Server, Framework, Documentation, Example Code, and Example Apps to potential customers. This story is to figure out what our options are to deliver AppStore, Assets, Radar, and Podium as runnable applications to clients as examples of what Ionic can do.

Things to consider:
How they will change the server endpoint to point to their servers.
How we will handle provisioning profiles.
Amount of time to implement solution
Legal risks

Possible options:
Putting the code on a CD.
Putting the apps on a CD with a config file to change server endpoints.
Giving them a configurable dev console.
Allowing them to upload provisioning profiles and server endpoints to a web app that we have open that creates downloadable apps for them
etc.

Deliverable with this story is at least two options that we can present to Mark that demonstrate pros and cons of each approach.

Put a version of both Podium and AppStore that hit Mobile Dev on a device and hand it to Zach for him to bang on. When he approves it, talk to Kenny and tell him we're ready for him to push what's on mobiledev-ionicmobile.asolutions.com to staging.

The apps we want approved are:
iOS AppStore
iOS Assets
Web Assets
iOS Radar
iOS Podium
mobiledev server stuff

Sweet!