WebOS Sync Period
Results 1 to 7 of 7
Like Tree2Likes
  • 1 Post By Zeus
  • 1 Post By vinzenz

Thread: WebOS Sync Period

  1. #1
    Active Member
    Join Date
    Oct 2012
    Posts
    18

    WebOS Sync Period

    I know it is not officially supported, but WebOS worked fine so far except for the calendar sync period.
    There is no configuration for that on the client, as far as I know it should sync unlimited into the future (past is not important).
    However, ZxMobile does not seem to understand this and sets it to the default 14 days period instead, which is quite short.
    Is there any chance to get a fix or workaround for that?

  2. #2
    The CEO ZeXtras Employee
    Participant
    Zeus's Avatar
    Join Date
    Apr 2011
    Posts
    57
    Hello Vinzenz and Welcome to the Forum !

    As you say WebOS is not Official supported but we are very happy you successfully tested it!
    About your Sync Period Issue... ZeXtras mobile can't set any kind of period because it is fully device-driven.
    The only way to find a work-around is Device-Side.

    Waiting hearing from you Soon. Best Regards.
    ZeXtras Website # ZeXtras Wiki # ZeXtras Store

    ZeXtras CEO. Like a Boss.

  3. #3
    Active Member
    Join Date
    Oct 2012
    Posts
    18
    Thanks for the welcome and your quick answer.
    I took a look into the MS ActiveSync Command Reference Protocol Specification to check the behavior of the FilterType element in a sync command to a calendar. Under 2.2.3.64.2 it says: "Calendar items that are in the future or that have recurrence but no end date are sent to the client regardless of the FilterType element value."
    If I understand it correctly, this means calender entries should be synchronized 14 days into the past, but always infinitely into the future.
    ZxMobile instead syncs 14 days in both directions, see extract from sync.log: "Getting items older(or newer) than 14 days for type: 11 on folder: /Calendar"
    Correcting this is surely not crucial for Android, which allows up to 6 months sync period, but it would help me a lot.

  4. #4
    ZeXtras Community Manager ZeXtras Employee Cine's Avatar
    Join Date
    Apr 2011
    Posts
    2,342
    Hello Vinzenz,
    thanks for the report!

    A fix for this behaviour is being tested and will be included in the next version of ZeXtras Suite...

    Have a nice day,
    Cine
    IT Support Team Contact Form
    Sales Team Contact Form

    ZeXtras Website
    # ZeXtras Wiki # ZeXtras Store

    Have ZeXtras Suite or ZeXtras Migration Tool been helpful to you?
    Share your experience in the Zimbra Gallery!

    ZeXtras Suite on the Zimbra Gallery
    ZeXtras Migration Tool on the Zimbra Gallery

  5. #5
    The CEO ZeXtras Employee
    Participant
    Zeus's Avatar
    Join Date
    Apr 2011
    Posts
    57
    Quote Originally Posted by vinzenz View Post
    Thanks for the welcome and your quick answer.
    I took a look into the MS ActiveSync Command Reference Protocol Specification to check the behavior of the FilterType element in a sync command to a calendar. Under 2.2.3.64.2 it says: "Calendar items that are in the future or that have recurrence but no end date are sent to the client regardless of the FilterType element value."
    If I understand it correctly, this means calender entries should be synchronized 14 days into the past, but always infinitely into the future.
    ZxMobile instead syncs 14 days in both directions, see extract from sync.log: "Getting items older(or newer) than 14 days for type: 11 on folder: /Calendar"
    Correcting this is surely not crucial for Android, which allows up to 6 months sync period, but it would help me a lot.
    Hi Vinzenz,

    I want to personally thank you for your great help.
    Your report was very useful and detailed.
    We just fixed this issue and will be available to all ZeXtras Suite users, thanks to your report, in the next version.
    I truly hope you will continue to use ZeXtras suite and to help us to improve it always more.
    To thank you for you help we will send you soon a little present (via Private Message).
    Last edited by Cine; 11-29-2012 at 08:11 AM.
    d0s0n likes this.
    ZeXtras Website # ZeXtras Wiki # ZeXtras Store

    ZeXtras CEO. Like a Boss.

  6. #6
    Active Member
    Join Date
    Oct 2012
    Posts
    18
    Hi Cine and Zeus,

    I updated yesterday and got happy feedback from webOS user.
    Thanks for correcting this so quickly and many thanks for the present!
    d0s0n likes this.

  7. #7
    Active Member
    Join Date
    Oct 2012
    Posts
    18
    Hi,

    I'm going to revive this thread, because I have another issue with WebOS. Since the last update, 1.8.6, messages are not displayed on WebOS devices anymore.
    In the log, I find the following exception in the corresponding device sync:

    sync - ZxMobile Handler: Exception: java.lang.NullPointerException
    at com.zextras.mobile.MailItemEncoder.encodeBody25 ( MailItemEncoder.java:340 )
    at com.zextras.mobile.MailItemEncoder.encodeMessage ( MailItemEncoder.java:495 )
    at com.zextras.mobile.MailItemEncoder.encodeMailItem ( MailItemEncoder.java:114 )
    at com.zextras.mobile.MailItemEncoder.encodeMailItem ( MailItemEncoder.java:95 )
    at com.zextras.mobile.syncop.Sync.doFetch ( Sync.java:719 )
    at com.zextras.mobile.syncop.Sync.doCommands ( Sync.java:925 )
    at com.zextras.mobile.syncop.Sync.handleCollection ( Sync.java:1062 )
    at com.zextras.mobile.syncop.Sync.doProcess ( Sync.java:367 )
    at com.zextras.mobile.ZEMobileHandler.managePost ( ZEMobileHandler.java:381 )
    at com.zextras.mobile.ZEActiveSyncBackend.handleActiv eSyncRequest ( ZEActiveSyncBackend.java:58 )
    at com.zextras.mobile.ZEActiveSyncBackend.doPost ( ZEActiveSyncBackend.java:33 )
    at com.zimbra.cs.extension.ExtensionDispatcherServlet .service ( ExtensionDispatcherServlet.java:99 )
    at javax.servlet.http.HttpServlet.service ( HttpServlet.java:820 )
    at org.eclipse.jetty.servlet.ServletHolder.handle ( ServletHolder.java:565 )
    at org.eclipse.jetty.servlet.ServletHandler$CachedCha in.doFilter ( ServletHandler.java:1361 )
    at com.zimbra.cs.servlet.SetHeaderFilter.doFilter ( SetHeaderFilter.java:57 )
    at org.eclipse.jetty.servlet.ServletHandler$CachedCha in.doFilter ( ServletHandler.java:1332 )
    at org.eclipse.jetty.servlets.UserAgentFilter.doFilte r ( UserAgentFilter.java:77 )
    at org.eclipse.jetty.servlets.GzipFilter.doFilter ( GzipFilter.java:218 )
    at org.eclipse.jetty.servlet.ServletHandler$CachedCha in.doFilter ( ServletHandler.java:1332 )
    at com.zimbra.cs.servlet.ZimbraQoSFilter.doFilter ( ZimbraQoSFilter.java:114 )
    at org.eclipse.jetty.servlet.ServletHandler$CachedCha in.doFilter ( ServletHandler.java:1332 )
    at org.eclipse.jetty.servlets.DoSFilter.doFilterChain ( DoSFilter.java:464 )
    at org.eclipse.jetty.servlets.DoSFilter.doFilter ( DoSFilter.java:327 )
    at org.eclipse.jetty.servlet.ServletHandler$CachedCha in.doFilter ( ServletHandler.java:1332 )
    at org.eclipse.jetty.servlet.ServletHandler.doHandle ( ServletHandler.java:477 )
    at org.eclipse.jetty.server.handler.ScopedHandler.han dle ( ScopedHandler.java:119 )
    at org.eclipse.jetty.security.SecurityHandler.handle ( SecurityHandler.java:524 )
    at org.eclipse.jetty.server.session.SessionHandler.do Handle ( SessionHandler.java:227 )
    at org.eclipse.jetty.server.handler.ContextHandler.do Handle ( ContextHandler.java:1031 )
    at org.eclipse.jetty.servlet.ServletHandler.doScope ( ServletHandler.java:406 )
    at org.eclipse.jetty.server.session.SessionHandler.do Scope ( SessionHandler.java:186 )
    at org.eclipse.jetty.server.handler.ContextHandler.do Scope ( ContextHandler.java:965 )
    at org.eclipse.jetty.server.handler.ScopedHandler.han dle ( ScopedHandler.java:117 )
    at org.eclipse.jetty.server.handler.ContextHandlerCol lection.handle ( ContextHandlerCollection.java:250 )
    at org.eclipse.jetty.server.handler.HandlerCollection .handle ( HandlerCollection.java:149 )
    at org.eclipse.jetty.server.handler.HandlerWrapper.ha ndle ( HandlerWrapper.java:111 )
    at org.eclipse.jetty.rewrite.handler.RewriteHandler.h andle ( RewriteHandler.java:312 )
    at org.eclipse.jetty.server.handler.DebugHandler.hand le ( DebugHandler.java:77 )
    at org.eclipse.jetty.server.handler.HandlerWrapper.ha ndle ( HandlerWrapper.java:111 )
    at org.eclipse.jetty.server.Server.handle ( Server.java:349 )
    at org.eclipse.jetty.server.AbstractHttpConnection.ha ndleRequest ( AbstractHttpConnection.java:452 )
    at org.eclipse.jetty.server.AbstractHttpConnection.co ntent ( AbstractHttpConnection.java:894 )
    at org.eclipse.jetty.server.AbstractHttpConnection$Re questHandler.content ( AbstractHttpConnection.java:948 )
    at org.eclipse.jetty.http.HttpParser.parseNext ( HttpParser.java:857 )
    at org.eclipse.jetty.http.HttpParser.parseAvailable ( HttpParser.java:235 )
    at org.eclipse.jetty.server.AsyncHttpConnection.handl e ( AsyncHttpConnection.java:77 )
    at org.eclipse.jetty.io.nio.SslConnection.handle ( SslConnection.java:191 )
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint.han dle ( SelectChannelEndPoint.java:606 )
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.r un ( SelectChannelEndPoint.java:46 )
    at org.eclipse.jetty.util.thread.QueuedThreadPool.run Job ( QueuedThreadPool.java:603 )
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.r un ( QueuedThreadPool.java:538 )
    at java.lang.Thread.run ( Thread.java:722 )
    It would be great, if you could investigate this issue. I will gladly help with any additional information.
    Otherwise I have to downgrade to 1.8.5. Is there an official procedure for that?

    Thanks for your help!

    Vinzenz

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •