Systems Russell Mickler Systems Russell Mickler

More Progress on Swift App - SQLite and TableViews

More testing and creation of an iOS app. Good results today, manipulating SQLite and creating a tableview from a query.

gif_contacts_v2.gif

More progress was made on my application today and, wow, it took me about six hours to do this, but I finally got it ... 

The animation doesn't really do the code justice, but what it's doing is:

  • Opens a Navigation Controller with the FMDB overlay for accessing SQLite structures - this will allow me to access a SQLite dbase and populate a TableView.
     
  • It looks for the dbase in the documents directory of the current user and, if it exists, drops tbl_contacts, re-creates tbl_contacts, inserts some bogus records into tbl_contacts, and cycles through tbl_contacts to append to an array that's passed to the tableview. All so I can get a selection of humans, as you see here.

The hardest damn thing was to get the code right for appending the values read from the SQL query into an array:

 

 // And populate the array

if let rs = contactDB.executeQuery("SELECT * FROM TBL_CONTACTS", withArgumentsInArray: nil) {

                while rs.next() {

                    // self.contacts = [Contacts(name: rs.stringForColumn("txtname"))]

                    contacts.append(Contacts(name: rs.stringForColumn("txtname")))

                    println("Cycling -")

                    println(rs.stringForColumn("txtname"))

                    }

                } else {

                    println("Select Failed: \(contactDB.lastErrorMessage())")

                }

                println("I'm done cycling")

Anyway, it was crazy how long it took me to get the syntax right, but now I've got a tool to open a dbase, create a query, cycle through the query, populate an array, and pass it to a view ... huge progress today. Much happiness.

R

Read More
Systems, Strategy Russell Mickler Systems, Strategy Russell Mickler

Start Worrying About EMV Transition in October 2015

image.jpg

Starting in October 2015, EMV (Europay, MasterCard, Visa) liability for credit card data breeches will shift from the processor to the retailer.

Technically, the language reads that the "most insecure" in the processing chain is responsible for breech, which extends financial liability back to the business accepting the credit card.

If you're a small business in the Vancouver, Washington or Portland, Oregon area that accepts credit cards, this transition affects you. There are three components of this transition that you must be aware of:

1. Your POS Readiness. The software and hardware that runs your point of sale system must be upgraded to support upcoming changes, including accepting new chipped cards. You should understand your vendor's upgrade schedule and look for gaps in that upgrade process. 

2.  Your PCI-DSS Compliance Status. The Payment Card Industry have implemented technical and administrative standards that help reduce risk of data breech. Not understanding your PCI-DSS status is a demonstration of managerial negligence that can expose your company. 

3. Training. The way you accept credit cards is going to change. With the new chipped cards, you dock the card instead of swipe it; phones will become methods of payment; banks are in the process of replacing cards and activating phone payment solutions; very soon, consumers are going to be showing up at your door expecting to use these new systems. You and your team should be ready.

Mickler & Associates, Inc. can help you with all three components of this problem. Please contact us for a no-cost discussion to see how we can help out.

R

 

Read More
Systems, Strategy Russell Mickler Systems, Strategy Russell Mickler

The Dangers of 3rd Party Apps and Keyboards

image.jpg

Apple released a new capability in IOS 8 that allows the user to replace their phone's keyboard with an alternative provided by a third party.

Applications like these can also replace the calendar functions on a phone as well as its contact functions.

When these apps are installed, the user gives permission to third parties (the developer of the app) access to their device. If it's a keyboard, that developer can convievably see anything that you type (like passwords, account numbers, or confidential information); like your calendar (which you may presume is private); or your contact list (who may not appreciate you sharing their information).

If you are subject to federal or state restrictions over classified forms of information (like HIPAA, GLB, or transferring social security numbers or drivers licenses), it's absolutely vital that you do not install these kinds of applications on your mobile device when working with your business account for mail, contacts, calendar, or drive. Just don't do it.  Don't install these applications. There's no guarantee of privacy if there's a middle man between you and your data.

if you're at all concerned about privacy and security, just don't do it. Don't install these applications.

if you use your device to take credit cards for your business, please - for the love of everything holy - do not install these applications.

If you do use these applications, bear in mind that the licensing agreement for use may stipulate what those third parties do with their access to your data. You may want to read those end user license agreements, usually found within the app or on the developer's website.

And if you have any questions, please feel free to reach out to me. I may be able to help coach you through your options.  Thanks.

R

 

Read More