Archived Forum Post

Index of archived forum posts


ANDROID: Email (POP3/IMAP) and using ASYNC

May 02 '16 at 08:20

We are working on an Android app for emails. Need to code in some ASYNC processing for threading issues (bit new for me) but not sure the best way to do this with Chilkat. Started going through the online examples but the website started popping "404 Errors - File or Directory not found" on any example.

So, started going through the actual documentation and not sure how best to proceed. Hoping someone on here can point us in the right direction.

A basic overview, our main thread lists a couple email accounts. Hitting a single button will cause the emails to be checked for new emails. Each "account" calls an update procedure independently.

This separate procedure: - puts in the account credentials in either MAILMAN or IMAP calls. - Logs into the server - Gets all the UIDLs - Compares them for new ones - Fetchs each new email as needed - Logs out

We will want each account to keep a progress bar or counter going as this is processing, individually.

Looking through the documentation, almost every main function (GetMailboxCount, GetUidls, FetchEmail,...) has an ASYNC version it seems. So the question is, do I call the ASYNC version for each function... "running" it individually, or do I some how wrap them all in a different ASYNC thread?

Any help or suggestions or direction... would be greatly appreciated.


Thanks, the web pages are updating now. Re-load the index page in your browser, and the links should be fixed. Each link was erroneously ending in ".ckx" instead of ".asp".


Just as a info after a quick test.

The Python example pages are still not working. (500 - Internal server error)

for Python at least it seems this is supposed to be the correct url:

But i am not sure what it is about CkPython. I am not even sure what CkPython is. ;)


Sorry about that! It's fixed now.

In the next version of Chilkat, a new Chilkat Python API will be introduced that uses memoryview's, and will no longer use the CkString/CkByteData objects. It will not use SWIG for C++ wrapper generation, but will instead be a much cleaner and more natural API for Python programmers. The problems you encountered on had to do with this.

Here's the first look at the new Python API. The old will still exist and be supported..

Here are some temporary URLs and notes:

A few notes:

Eventually Ruby and Java will go the same route: / chilkat.ckjava and the same for Ruby.