ibm / bluepic Goto Github PK

See https://console.ng.bluemix.net/docs/services/mobileaccess/getting-started-ios.html.

Also, see the MIL/BluePic app.

The info on the Bluemix app that we can use in the meantime before we can have a Kitura-based app is described in issue #25.

To invoke the REST endpoints on the Kitura-based server, we should leverage the MCA SDK client.

See the following resources:

• https://github.com/ibm-bluemix-mobile-services/bms-clientsdk-swift-core

Add logic to leverage the Swift-cfenv package: https://github.com/IBM-Swift/Swift-cfenv.

Currently in progress (Anton working on this).

Fixed bug in their code line 326 in the AuthorizationRequestManager.swift... It was:

guard let unWrappedObj = obj else {
return nil
}

When it was like this it was causing a "ambiguous use of subscript" error

I changed this code to:

guard let unWrappedObj = obj as? [String] else {
return nil
}

It was trying to treat an anyobject as an array, which you can't. So I casted it as an optional array of strings. Fixed the issue

As a user of the iOS app, I should be able to select or enter a text tag to look up images. Images that Watson has tagged with the chosen text tags should then be returned.

• The inputs are: 1) the geolocation (latitude and longitude values) where the picture was taken, 2) the units of measure to use (imperial vs. metric), 3) the language locale (e.g. en-US), and 4) the record ID for the corresponding image record in the Cloudant database.
• The output from the Weather API integration is the current weather condition for the given geolocation. Specifically, the "temp" and "sky_cover" (current condition) values from the output should be stored in the corresponding Cloudant JSON image record. Each JSON image record has a location JSON object, which contains a temperature field and a weather field.

1. Include in the manifest.yml file the remaining CF services used by the app:

• Push
• MCA

2. Also, update BluePic-Server/resources/cloud-foundry/services.sh accordingly.

Secure only the following endpoints using the new MCA SDK for the server:

• get("/users/:userId")
• get("/users")
• post("/users/:userId/images/:fileName/:caption/:width/:height/:latitude/:longitude/:location")
• post("/users")

Please note that securing the /users/:userId/images/:fileName/:caption/:width/:height/:latitude/:longitude/:location POST endpoint implies that:

• The userId (Facebook ID) is retrieved from the MCA server SDK.
• Simple logic should then be implemented to validate that the userId request parameter in the URL matches the Facebook ID retrieved through the MCA SDK on the server. If they don't match, then we throw an error (user is not authorized). For the other endpoints listed above, we don't need to perform this validation.

https://github.com/ibm-bluemix-mobile-services/bms-clientsdk-swift-security-facebookauthentication/tree/development

This file would be consumed by the OS X app. This item is for a subsequent version of the OS X app. In the meantime, we just plan to create a README that states how to populate the Bluemix services. Therefore, this item more than likely will be deferred for later.

• Once the AlchemyVIsion API and Weather API OpenWhisk interactions have completed, a push notification should be generated to let the user know that the system has saved metatada for the picture he/she uploaded.
• An POST endpoint (/push/images/:imageId) is already defined on the Kitura-based server that should be invoked by the OpenWhisk sequence (as the last step) to send the push notification to the iOS client. The Kitura-based server will then use the Push SDK (Swift 3) to send out the push notification. The last item/value in this endpoint should be the imageId of JSON image document stored in Cloudant.

This is because of AlamoFire and ObjectMapper, libraries that we may not need or that we can install with Pods.

This will be used by the OS X app and GitHub.

See following list of files/folders:
drwxr-xr-x 19 olivieri staff 646 Apr 15 11:45 KituraBluePic
drwxr-xr-x 5 olivieri staff 170 Apr 15 11:45 KituraBluePic.xcodeproj
drwxr-xr-x 3 olivieri staff 102 Apr 15 11:45 KituraBluePic.xcworkspace
drwxr-xr-x 4 olivieri staff 136 Apr 15 11:45 KituraBluePicTests
drwxr-xr-x 4 olivieri staff 136 Apr 15 11:45 KituraBluePicUITests

Once files/folders renamed, update .gitignore accordingly.

Kitura-BluePic was forked before development of MIL/BluePic was completed. We should bring into this repo any bug fixes and functionality [from MIL/BluePic] that is applicable to this new version of BluePic.

Implement scaffolding for processing push notification from server.

• The inputs are: 1) image/picture (NSData) and 2) the image record ID for the corresponding record in the Cloudant database.
• The AlchemyVision API is then used to process the image to perform object and scene recognition.
• The output from the AlchemyVision is a list that contains one or more classifications along with the confidence level (e.g. "dog", 99%). This output should be stored in the corresponding image JSON document in Cloudant under the tags field.
• There's a new method in the RouteUtils.swift file (invokeOpenWhisk()) that will server as the starting point for kicking off the OpenWhisk sequence.

• https://github.com/ibm-bluemix-mobile-services/bms-clientsdk-swift-core
• https://console.ng.bluemix.net/docs/services/mobilepush/t_enable_ios_notifications_install.html

Computed metadata for images includes: temperature and image tags (e.g. object identification, scene recognition):

• Dedicated screen for viewing above data.
• Link on the image feed to access the dedicated screen.
• Tags counter.

As a user, I should be able to enter a text tag to look up images. Images that Watson has tagged with that text tag are then returned.

Put/Post should update a variable on the server.
Delete should wipe it out.

Metadata for images shall be stored in Cloudant while the image binary shall be stored in Object Storage.

As a stopgap solution, we should use the Kitura-CouchDB package.

The Object Storage SDK needs to be refactor so that it can execute on Linux.

Even after upgrading to the latest iOS version, it still complains on one line in the AuthorizationRequestionManager.swift saying “Ambiguous use of subscript".

We may have to reach out to Matt/Anton on this one.

We plan to use the Mobile Client Access SDK for iOS to perform REST invocations from the iOS app to the server.

We need to implement a shell script for OS X that installs any system dependencies needed for running the BluePic sever using homebrew. This script should also start the BluePic server (more details to come). It is assumed that homebrew has already been installed by the user. It is also assumed that the Swift binaries were installed by the user.

Command for installing depedencies:
brew install http-parser curl

Command for building the project:
make clean
make

Command for starting the server:
/.build/debug/Server

Let's put this script at the root level of the repo.

The Kitura team is currently working on migrating the code to 4-25 binaries. This task is blocked until that task is completed.

To improve the developer experience, let's reinstate the approach we used for MIL/BluePic:

• Check in the Pods directory into source control. In other words, as part of setting up the Xcode project, you run the "pod install" command on your system, and then you push to Git everything. Developers that pull the Xcode project from Git can compile the project right away, without having to install any pods.

The current approach puts the responsibility on the developer to install the Pods themselves.

Benefits with this approach (see this URL: https://guides.cocoapods.org/using/using-cocoapods.html):

1. Missing info on README.
2. Demo app does not work.

There should be at least two schemes:

• One for building the iOS project.
• One for building the Kitura-based project.

The schemes/targets should be set up accordingly to ensure the right projects are built.

Let's try to have the workspace file at the root folder of the repo (as a peer to the BluePic-iOS and BluePic-Server folders).

Clarification: Schemes cannot be bound to a specific toolchain. Instead, the developer will have to manually switch the toolchain depending on the project they want to work on (iOS vs. Server).

MIL/BluePic has this functionality in place. We should bring it over to this version of BluePic.

Restructure repo as follows:

1. Rename these folders:

• KituraBluePic-iOS -> BluePic-iOS
• KituraBluePic-server -> BluePic-server

2. As peer to the BluePic-iOS and BluePic-server folders, create a new folder:

• BluePic-OpenWhisk

3) Delete current .gitmodules file. (let's keep this file for now)

Details:

• BluePic-iOS will contain the iOS app source code. For the development of this component, we will use the Swift 2.2 toolchain.
• BluePic-server will contain the Kitura-based server component. This folder should contain a valid SPM Swift package. For the development of this component, we will use the Swift 3 development toolchain.
• BluePic-OpenWhisk - This folder contains any Swift code for the implementation of OpenWhisk actions/sequenences. Note that this is not a SPM Swift package or an Xcode project.

This view/page does not exist in the MIL/BluePic version. This page was added to the Kitura-BluePic version. Though this page made sense for that effort, for this new embodiment of BluePic, we don't have a use case for it.

• This endpoint will leverage the Push SDK (Swift 3.0) that Anton's team will deliver.
• See the following code in the Route.swift class:

// Endpoint for sending push notification (this will use the new Push SDK)
router.post("/push", handler: closure)

App has been created and can be accessed here: https://console.ng.bluemix.net/?direct=classic/#/resources/orgGuid=0cdab6d0-7ec0-470c-a97f-0e26f6228cbf&spaceGuid=4c549a92-b20e-419b-b5b1-fb58daf4af2c&appGuid=75eef52c-2ed1-4518-9587-ce55cc66479d&detailType=overview&paneId=2

App has the following services: Cloudant, Object Storage, Mobile Client Access, and Push.

App route: http://IBM-BluePic.mybluemix.net
App GUID: 75eef52c-2ed1-4518-9587-ce55cc66479d

This app uses Node.js as the server for now. We won't be adding any logic to this Node.js instance (we just needed a web server to create a CF app). We will be yanking out this Node.js server and replacing it with a Kitura-based server.