Friday, October 16, 2020

LG V35 Home Screen Crashing with "Home is not responding." message

I like my LG V 35 Android phone. It is fast, has a kick-ass sound chip and worked perfectly for the


longest time. But, all of a sudden it would not open the Home screen (pressing on circle from bottom phone menu) anymore.

This should take half a second at most, it started taking 30s plus, with screen turning black. The Home screen would, then, completely reload.

The message "Home screen is not responding. Do you want to continue to wait or quit?" would sometimes appear.

I rebooted and it would work for a bit. Started to delete downloaded apps. Looking at Internet boards to see if this problem has been encountered by others. It did not seem like others were seeing this.

I was getting desperate since the only other solution suggested was to reset phone back to factory settings.

Last try using safe-mode to double check things. Unfortunately, the behavior did not go away in safe-mode. This made me look into the core applications that are shipped with the phone, since in safe-mode, nothing else is running.

More twiddling and experimenting followed.

The solutions was simple but indicated a bug in the Google Mail application when working with Office 365 email accounts. I removed a Microsoft Office 365 account I had recently added. When Google Mail was connected to this account it would hang up the phone's home screen. Making the phone nearly unusable since you cannot effective navigate between apps.

Odd.

I downloaded the Office Outlook for Mobile app for my office 365 account and my phone works again. I can check the email without hanging up my phone.

If you are finding yourself in a similar situation I hope this helps.

Cheers,

Bilal



Tuesday, June 16, 2020

ReactNative: Quickly integrate contactless payments into your react-native projects

Quickly integrate contactless payments into your react-native projects

Trying to go out an build a contactless payment solution from scratch is not something that everyone has the time and gumption to do. As far as approach there are principally two successful approaches to contactless one can follow. The RFC and the QR methodology.
The RFC Methodology
This ist the incumbent process in most of Europe and North America. Buyers use an RFC chip based Credit or Debit card or mobile device. Buyers swipe the device over a specialized card reader and seller, then, connects to card or payment processor.
Popular implementations of this in the US for mobile devices are represented by Apple Pay and Google Pay. The issue for us what that this method had a few drawbacks:
  • We needed to have special hardware. Some of which has be rented on a monthly basis by the seller (merchant).
  • It really wasn't completely touch free. Debit cards still required touching the seller terminals. Other terminals required confirmations on occasion.
  • Getting up and running in a real world store was not a matter of hours, but weeks and months.
The advantages were that users mostly are familiar with the payment processes in the US.
The QR Methodology
This is the Asian model and very popular in China. Both AliPay and WeChat pay and some others use this as their standard of starting the payment processing cycle.
The drawbacks here are users in US and Europe are less familiar with this methodology then they are with others though this is quickly changing. We see more users becoming familiar with QRs for other purposes besides advertising. Users now see them in restaurants for menu lookup and on rentals when renting scooters or bikes.
Thus the drawbacks:
a) User familiarity with process
b) Since processing occurs on different device than payment initiation closing the payment loop requires effort on programmers.
The advantages are that this, when done right, is:
a) Very quick to implement since no other hardware is needed
b) Very inexpensive for seller (merchants)
c) Can be truly contactless even with debit cards
d) Can close the payment loop even when process is distributed across devices.
Thus, in this tutorial we will focus on QR based contactless payments and show you how to quickly get started using them in your react-native based mobile applications.
We use the XcooBee contactless payments since it needs very little effort while providing many options as well as the ability to close the payment notification loop. capabilities and programming in the app.

Getting Started from Scratch

Prerequisites:

Setting up Payment Processing Backend

In our example, you will need a XcooBee Professional account and a Stripe account. Both of these are free to setup. Use the video tutorials or web tutorial to configure your first XcooBee Payment Project. This sets up you base infrastructure to process payments for your app. This is what you will need to do all the back-end processing.

The App

You can use create react native (CRA) or Expo project as baseline for our example. We will use Expo based version.
If you have never installed expo first install the command line tools:
npm install expo-cli --global

Create Your Expo Project

Creating your expo project is also straight forward.
expo init myPayProject => select blank (with Typescript)
cd myPayProject expo start
The last command should start a expo session with your expo app.

Install libraries

Now that we have a base app lets add the needed libraries
yarn add react-native-svg => adds needed SVG support for vector graphics
yarn add @xcoobee/react-native-xcoobee-payment-sdk => adds the XcooBee libraries

App.tsx

There is only one file that we need to change. That is App.tsx.
Add import statement to your import section. import XcooBeePaySDK from '@xcoobee/react-native-xcoobee-payment-sdk';
Follow this with initial configuration of the payment SDK. Here is where you could set Expo Install Id etc. if you need to communicate back to your device about success and failure. For our purposes the only needed config items are campaignId and formId. You can find these values in your XcooBee Payment Project summary page. Replace your values instead of using the example values.
XcooBeePaySDK.setSystemConfig({ campaignId: 'e98.eg0000000', formId: 't000' });
The remainder of the code is only a few <Text> to display labels, one <TextInput> to have the user enter the amount they wish to charge. The default is $1.
Your App.tsx should look like this:
import React from 'react'; import { StyleSheet, Text, TextInput, View } from 'react-native'; import XcooBeePaySDK from '@xcoobee/react-native-xcoobee-payment-sdk'; // TODO: replace with actual values from XcooBee Payment Project // Open your payment project in edit mode and review the summary screen XcooBeePaySDK.setSystemConfig({ campaignId: 'e98.eg0000000', formId: 't000' }); export default function App() { const [chargeAmount, setText] = React.useState('1.00'); const XcooBeePayQR = XcooBeePaySDK.createPayQR(parseFloat(chargeAmount)); return ( <View style={styles.container}> <Text> How much do you want to charge: </Text> <TextInput defaultValue='1.00' style={{textAlign:'right' }} onChangeText={text => setText(text)} value={chargeAmount} /> <Text style={{ marginBottom: 20, marginTop: 20 }}>Please scan and pay</Text> {XcooBeePayQR} <Text>powered by XcooBee</Text> </View> ); }
Most of this is boilerplate generated by Expo during project creation. With this line we define the QR object and amount we want to represent: const XcooBeePayQR = XcooBeePaySDK.createPayQR(parseFloat(chargeAmount) where the createPayQR is the main function from the Payment SDK and chargeAmount is the amount we wish to charge buyer-user. See the Payment SDK documentation for additional options of types of QRs that can be generated and call options.
When we wish to render we use the QR object like this {XcooBeePayQR}.
This will add the QR in your current render container.
Here is the application when running (this example uses invalid project codes so the payment cycle cannot be started):
Example react native app running

Using our Pre-Build example

Of course we have already pre-build app you can experiment with if you do not want to go through all the steps. You will still need a XcooBee Payment Project setup completed if you want to process payments (test or live).
Please replace the campaign Id and form id in App.tsx
Expo Code GitHub Example
You can also clone this to your local machine like so:
git clone https://github.com/XcooBee/example-payment-sdk-react-native.git

Congratulations

This is all it takes to have an app that can accept contactless payments.
Of course, there are many more options for QR and direct Payment URL generations than this sample can show. Feel free to experiment with the XcooBee Payment SDK, XcooBee Professional Account, and Stripe or Paypal payment processing.
Pro tip: If you use Stripe test accounts or Paypal Sandbox accounts you will not incur any XcooBee charges either.
You can experiment and refine from here.

Cheers,
Bilal

Monday, April 24, 2017

node: creating a debugger setup for visual studio code and mochajs for typescript tests

The title of the post says everything that I wanted to say. I have been looking at how to create a more streamlined environment for my nodejs typescript development.
I was specifically interested in how to start only a specific test with the interactive debugger. I did not want to change the launch config every time I worked on a new test and I also wanted to handle mocha test  written in typescript.

I normally have a tsc process started in separate command window running tsc -w command.This watches all files and compiles when needed.

Here are the changes I made to Visual Studio Code and my environment.
In my project I installed:

  • typescript
  • mocha
  • mocha-typescript


I decided to hide all TypeScript generated files via adding a files.exclude directive to my USER SETTING  (access via File:Preferences:Settings), like so:

"files.exclude": { "**/.git": true, "**/.svn": true, "**/.hg": true, "**/CVS": true, "**/.DS_Store": true, "**/*.js.map": true, "**/*.js": { "when": "$(basename).ts"} }

Then came the harder part. Finding a launch.config elements that would work (access via Debug:Open Configurations). I wanted to be able to open the debug pane and open the typescript test file I was working on, set breakpoints and click on "Start Debugging" button (green play button) and have the process kick off correctly.

This was not as trivial as I initially envisioned and much googling and blog reading ensued.
Here is the launch.config segment that worked for me.


{ "type": "node", "request": "launch", "name": "Debug TS mocha", "program": "${workspaceRoot}/node_modules/mocha/bin/_mocha", "stopOnEntry": false, "args": ["${fileBasenameNoExtension}.js","--no-timeouts", "--trace-warnings","--colors"], "cwd": "${fileDirname}", "sourceMaps": true, "outFiles": [], "env": { "NODE_ENV": "testing"} }


This works well with standard mocha js test as well as typescript test files. For typescript you need to either have a watcher going or add a preprocess to the launch.config that transpiles your typescript first.

Hope this will save someone the head scratching I went though.

Cheers,
B.



Thursday, March 9, 2017

node: A deeper look into npm (Node Package Manager)

Our topic for our last NodeJs user-group meeting was npm.
npm is automatically included when Node.js is installed. npm consists of a command line client and a remote repository. The command line client, of course, interacts with the remote registry. This combination allows users to consume and distribute JavaScript modules that are available in the repo. It was created in response to what its creator said "module packaging done terribly". There are many elements in this toolbox, did you know you can use npm without node??
Here are the slides of our deep dive. Hopefully it gave all of you who attended a better understanding a few helpful tips and tricks.
Best,
B.

Thursday, September 15, 2016

nodejs: Continuous Code Deployment using Node.js and AWS Stack

Yesterday we had our monthly Node.js usergroup meetup. I want to thank all for coming and exchanging interesting ideas for us to ponder.

We looked into how to create a complete deployment cycle using cloud technologies to support our node development.

We reviewed the complete process (build, test, deploy) and how tools like:
- AWS CloudPipeline
- AWS CodeCommit
- EBS (Elastic Bean Stalk)

We also used Solano Labs CI build service which is a cloud based alternative to build tool like Jenkins.

Building a continuous deployment cycle can change the game for even small shops to roll out quality code from development to production in very little time.

Here are the slides from the presentation, this will probably help those that were taking diligent notes. Most command line text are present on the slides.

http://downloads.boncode.net/downloads/CharlotteNodeJSSeptember2016.pdf

Cheers.
B.


Saturday, September 10, 2016

serverless: Serverless Framework and ethics vs the shiny object dilemma

For the last little while I was working on serverless concepts and exploring the Serverless Framework. It allows me to automate many manual steps but at the same time  it also imposes its way of thinking. Thus, it is a highly opinionated framework.

Though one can be of different opinions some of the good things provided by this framework are the ability to organize your project locally, abstract configuration, and deploy to different clouds from the command line.

The local development and testing paradigm is still rough and docs and examples are rather high level in many places.

It is also very much at the beginning stages with version 1.0 just about to be released. As such it has an enthusiastic crew with a lot of passion to push things forward. So, in short it is the new shiny thing that is cool and thus enjoys mindshare and interest.

In general that is a good thing. In particular, I can already see that there are cracks in the foundation. Two things in particular come to mind:

A) Dogma 


There is a sense of "we know better what you need" that permeates much of the later work on this framework. Whether it is through heavy configuration driven mechanisms in lieu of any convention elements or the careless breaking of implementation from earlier beta releases. For example, here is just a sprinkling of frameworks that believe in less configuration is better:


  • Apache Maven
  • Appcelerator's Titanium Alloy
  • ASP.NET MVC
  • CakePHP
  • ColdBox Platform
  • Contao
  • Crosslight
  • Durandal (JavaScript SPA Framework)
  • Ember.js
  • Enduro.js
  • Grails
  • Java Platform, Enterprise Edition
  • Laravel
  • Lift (web framework)
  • Meteor (web framework)
  • Play Framework
  • Roxy rest-API
  • Ruby on Rails
  • Sails (web framework)
  • Spring Framework
  • Symfony
  • Yii


This does not appear to be relevant to the current team and my fear is that the shininess will not overcome the effort it takes to maintain this when an alternate framework emerges. Ignorance in this case is not bliss.


B) Ethics of Tracking


The framework uses automatic enabled tracking of usage data. To discover this you will need to dig deep into docs and code. I understand that this is anonymous, however, this is not the way to approach the issue. Take Apple's location tracking for example, it is anonymous as well. How good do you feel about it?

For me the issue is with the enabled by default attitude. It is the complete undermining of faith of the user community. I believe firmly that any company making the automatic assumption of collecting data about me is living on the edge of ethics. Rather than playing in the muck, I would like to encourage the team to elevate themselves from questionable practices. There is time, and there are better alternatives.


Yes, you can disable all this once you find out where in the documentation it is hidden and run the right commands. This is not the point. If you don't ask me assume that you should not do it.

Here is the disable command if you are looking for it (run against all instances and all machines that you own):

$ serverless tracking --disable


Conclusions


So in short, this framework has potential but it is sliding into the area of big, obtuse, and rather in-the-way-of-the-task with ethical dangerous undertones before even hitting version one. These are achievements we should not be proud off given the great promise that it has.

If you have a project that is small or medium sized there are alternatives that work equally well and don't involve you sharing your personal command history. You still get automation and deployment in place with full control. Look at connecting AWS Code Commit to Lambda through Continuous Integration Pipelines via CodePipeline. That is some sweet stuff.

I am planning on outlining how to do this in more detail in later posts.
I will also put some things on serverless how-tos as contrast. There is good stuff there so an eye should be kept on it.

Cheers,
B.



Thursday, April 14, 2016

node: April 2016 Charlotte Node.js User Group material

Folks please find the links to the presentation materials and code samples from our April 2016 Node.js meeting. I hope this will get you kickstarted with node:

The presentation slides
The sample code

Here again the objectives from out meetup "Kicking it with Node, starter edition" :
By popular demand we will focus our sessions on how the node ecosystem works. This will include the setup of the environment the idiosyncrasies of JavaScript and base understanding of the event loop and asynchronicity.

So in the next session we will look at some of this:

  • installing Node.js 
  • understanding async tasks 
  • understanding the event loop 
  • what are callbacks  
  • creating projects 
  • understanding node modules and packages  
  • organizing code  
  • writing your own module 
  • what is the package.json file 
  • managing 3rd party packages with npm 
  • the require system 
  • exploring core module examples in node

Cheers,
B.